publicdebates on Show HN: Cicada – A scripting language that integrates with C

Comment on Show HN: Cicada – A scripting language that integrates with C

The for loop is odd. Why is the word counter in there twice?

    counter :: int

    for counter in <1, 10-counter> (
       print(counter)
       print(" ")
    )

Using backfor to count backwards is an odd choice. Why not overload for?

    backfor counter in <1, 9> print(counter, " ")

This is confusing to me. Maybe I'm misunderstanding the design principles, but the syntax seems unintuitive.

briancrOP7mo

Yeah this is why the syntax is customizable.. maybe it’s not optimal.

The example I gave was strange and I’ll have to change it. Not sure what I was trying to show there. The basic syntax is just:

for counter in <1, 5> print(counter)

backfor counter in <1, 5> print(counter)

It’s not overloaded because ‘for’ is basically a macro, expanding to ‘iterate, increment counter, break on counter > 5’ where ‘>’ is hard-coded. If ‘for’ was a fundamental operator then yes, there would be a step option and it would be factored into the exit condition.

You’ve got me thinking, there’s probably a way to overload it even as a macro.. hmmm…

nextaccountic 7mo

Just do for counter in <1, 5>.rev(), which would iterate in a reversed range.

IMO it's poinless to distinguish synctactically between iterating forwards and backwards, specially if you also support things like for counter in <1, 5>.map({ return args[1] * 2) to irate on even numbers (the double of each number), rather than having to define a fordoubled macro. I mean, adding method like map and rev to ranges is more orthogonal and composes better. (See for example iterators in Rust)

Not that I don't like syntactic flexibility. I am a big fan of Ruby's unless, for example

briancrOP7mo

“IMO it's pointless to distinguish syntactically between iterating forwards and backwards” — I completely agree. It’s really a compiler-macro limitation that’s preventing me from doing this.. though I don’t have to go that route.

I think what you’re suggesting would require the <a, b> syntax to produce a proper iterator type, which it doesn’t currently do. That’s definitely worth considering — then you could attach methods, etc.

Thanks for the suggestion! I’ll think about the best way to fix this..

Comments