SYNTAX: Passing lists with -> ?

[Guy Adini]

Another syntax question/proposal:

I think that we would like to allow passing lists as atoms.

For example:

read data -> <calculate a list of features> -> [mean, std, probability_through_svm] -> print

Now, when the -> operator gets a non-ignored iterable (i.e. not a str, unicode, dict), each of the elements of that

iterable are processed individually.

Wouldn't it be a nice feature if we had a different operator (maybe -*>, or something similar) which would pass the list as an atom?

Thanks,

Guy

[Guy Adini]

BTW, a very natural example would be:

list of files -> [read_features -*> normalize -*> dimension reduction / PCA -*> apply_learned_model -> output]

--
You received this message because you are subscribed to the Google Groups "pythonect" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pythonect/-/AwZEczAtXCoJ.
To post to this group, send email to pyth...@googlegroups.com.
To unsubscribe from this group, send email to pythonect+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pythonect?hl=en.

[Itzik Kotler]

Hi Guy,

Right now you can escape a list or a tuple from being iterated (i.e. make it an literal/atom) by wrapping it with another pair of brackets. e.g.:

[[1,2,3]] -> print will result in '[1,2,3]'

and

[1,2,3] -> print will result in '1', '2', '3' (or any other combination, as -> is async operator and items order is not guaranteed)

My guiding principle is to keep the language operators (i.e. '|' and '->') as simple/abstract as possible, and define attributes using keywords or other identifiers.

Something along these lines:

C-style casting:

(discrete) [1,2,3] -> print

C++ template style:

discrete<[1,2,3]> -> print

C# style attribute:

[discrete]
    [1,2,3] -> print

Functional programming style:

discrete([1,2,3]) -> print

and etc.

On Thu, Aug 30, 2012 at 2:56 PM, Guy Adini <guya...@gmail.com> wrote:

[Guy Adini]

Oh, right.

I just saw that you did that in the join example of the tutorial.

About the syntax - makes sense (and good to know).

[Itzik Kotler]

I also thought about using backslash (i.e. '\') as an escaping character. e.g.:

\[1,2,3] -> print (as oppose to: [[1,2,3]] -> print)

And perhaps even extending it to functions return value. i.e.:

\list([1,2,3]) -> print

But the problem with using backslash is that it's already used in Pythonect to join between two or more physical lines. i.e.:

"Hello, world" \
    -> print

So if we combine the two together we get:

\[1,2,3] \
    -> print

And I think it's a bit confusing.

[Guy Adini]

I also find it pretty confusing.

Not because of the no-EOL backslash (to which most *nix users are already used to, and pretty much ignore, I guess), but because of situations where a function has multiple return values, i.e.:

Image.open('img.jpg') -> \ calc_multiple_features() -> crunch_features() -> ...

The backslash before the calc_multiple_features function doesn't give a hint about what's being escaped, or why.

Of the other options, I liked the C-style (discrete) and and the functional discrete() best, but it's probably just what I'm used to.

Another option might be to use the percent/modulo sign ( %[1,2,3] -> print) - I noticed

that Ipython uses that for it's magic functions, so it can't be to horrible to put in the beginning of expressions, 

and it looks pretty nice IMO.

[TL]

I'm siding with Guy's original proposal, with a small modification to it.

I think passing iterables can be with the normal -> operator, and iterating through them can be -*>, meaning passing the iterable should be the rule and not the exception.

For example:

>>> range(5) -> print

[0, 1, 2, 3, 4]

 

>>> range -*> print

<MainProcess:Thread-2> : 0

<MainProcess:Thread-3> : 1

<MainProcess:Thread-4> : 2

<MainProcess:Thread-5> : 3

<MainProcess:Thread-6> : 4

Though it challenges some concepts of the language (focusing on minimalism and defaulting to demultiplexing), I think this syntax is more intuitive and less error-prone.

Also in my own mind the "*" sign is subconsciously associated with multiplying, so it fits ;)