Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Iteration

Does Harlowe implement any iterators?

For instance, if I have:

(set: $items_here to (array:"a stick","a length of string"))
is there some way to get the output below?

[quote]
There is a stick here.
There is a length of string here.

Comments

  • Try the following:

    (set: $items to (a: "a stick", "a length of string"))

    (print: "There is " + $items.join("\nThere is "))
  • ahh, I see how that works. Thanks!
  • FWIW I don't strictly endorse using Javascript-style function calls in Harlowe expressions, but since these occasions provide me with real-world usage examples that allow me to "pave the cowpath" in future Harlowe updates, I'm fine with them whenever existing macros are lacking.

    Iteration is something that I still need to do, because I don't yet have a lambda/function syntax. I've been mulling over something like the following:

    (array-join: $a, |(text: "There is " + input + ". ")|))
    (set: $lambda to |(text: "There is " + input + ". ")|) (array-join: $a, $lambda)
    where the pipes denote a "deferred expression", one that isn't evaluated immediately (a distinction I believe is important enough to merit special brackets, akin to a string of markup being "deferred markup"), and "input" is a keyword denoting the input to the lambda (at the moment only special macros like (array-join:) would be able to call a lambda, unless I also invent a call syntax).

    (You may remember my issues with clarity of evaluation time being why I removed the (when:) and (whenever:) macros before release, replacing them with the more verbose (live:). If I add this deferred expression syntax, they may make a return.)
  • Is there a reason why the standard for, for-each $item in $list, while, or loop statements found in most procedural languages wont suffice?
  • I've had it as something of a goal in Twine 2 development to make its macro syntax favour functional constructs over imperative ones. That's the reason why arrays/datamaps are kinda-sorta-immutable (the (set:) macro used on a property being a somewhat awkward but justifiable deviation) and (as of 2.0.1) compared by value, and why an apparently imperative macro like (if:) actually evaluates to a boolean, and (replace:) actually evaluates to a special "command" value (as evidenced by (print: (replace: ?gee)), which prints "[A 'replace' command]"). The guiding principle is that the markup, prose etc. is inherently declarative, so the code syntax should strive to be declarative as well.

    THAT BEING SAID I have to deal with the issue that most functional iteration functions have slightly bad names ("map", "reduce", "fold" etc.) so I'll have to be sure I think of particularly clear ones when I add these macros.
  • Would C#'s lambda notation work?
    (array-reduce: $a => (text: "There is " + input)))
    It sort of looks like the link, and the normal brackets would encapsulate the function behaviour. Then again:
    (array-reduce: $a, (action: (text: "There is " + input))))
    Would be more flavour consistent, but also verging on Lisp. But we're getting that way already. At some point in the future bracket highlighting would be great but I'm managing just about okay with hooks within hooks within hooks. It's a lot more versatile than 1.x was.
  • st33d wrote:
    (array-reduce: $a, (action: (text: "There is " + input))))
    I can't do specifically this because it violates the principle of evaluation I've been upholding so far: every argument in a macro call is evaluated at call time, and no "magic" macros like this (action:) dealie can bend the rules. Hence the need for special syntax to warn the author that the expression evaluation is deferred.
  • L wrote:

    THAT BEING SAID I have to deal with the issue that most functional iteration functions have slightly bad names ("map", "reduce", "fold" etc.) so I'll have to be sure I think of particularly clear ones when I add these macros.

    For Iteration maybe each or for_each?

    (I know us programmers like to apply new meanings to existing things but standard English words can be your friends)
  • I like the descriptiveness of each. It doesn't strike me as inherently imperative in the way that "for"/"while" are. Mind, I haven't done any functional programming since early in college, around 10 years ago, so I'll refrain from pretending I have deep thoughts on the topic :)
Sign In or Register to comment.