list comprehension patterns

list comprehension patterns

[Per Bothner]

I posted a new blog article:
http://per.bothner.com/blog/2017/list-comprehension-patterns/

Feedback welcome.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: list comprehension patterns

[Sudarshan S Chawathe]

> I posted a new blog article:
> http://per.bothner.com/blog/2017/list-comprehension-patterns/

I enjoyed reading this blog article.  The dot-product definition is
especially nice.  In general, I look forward to more pattern-matching in
Kawa.

Minor point: I found the comparison of outer-product to a database's
"outer join" confusing.  If I'm not mistaken, the operator is more like
a database's cross product (or "cross join").

Regards,

-chaw

Re: list comprehension patterns

[Andrea Bernardini]

Quite interesting article, I found some minor typos/issues

* Where you say Kawa-specific "|" do you mean Kawa-specific "!" ?

* There is a repetition in this sentence "A "scan context" is is an expression"

* "and then result sequence is "spliced" into its context." You meant
"and the result"?

* Another repetition and the sentence is not completely clear "When in
the scope of two more more distinct scan variables then are scanned
"in parallel""

* I think what you call outer join should be called Cartesian product
or cross join


Regarding the hypothetical filtering syntax

(! [a ...] A #!if (P a))

what about using one of 'when', the first is inspired by the single
branch if in Racket (where the 'if' keyword is replaced by when).

(! [a ...] A when (P a))

Also 'where' or 'on' could be possibilities.

The ellipsis syntax is nice, however when more scan patterns are
nested together can be confusing, have you considered using two dots
instead of three

#|kawa:31|# (define (fun2 [[x ..] ..] [y ..])
#|.....32|#   [[(+ x y) ..] ..])

just thoughts

Cheers,
Andrea

On 17 May 2017 at 18:00, Per Bothner <per@bothner.com> wrote:
> I posted a new blog article:
> http://per.bothner.com/blog/2017/list-comprehension-patterns/
>
> Feedback welcome.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

Re: list comprehension patterns

[Helmut Eller]

On Wed, May 17 2017, Per Bothner wrote:

> Feedback welcome.

It seems like an interesting idea. In particular, I like that these
patterns naturally support scanning in parallel without zip.  The need
for zipping always feels like a shortcoming in Python/Haskell.

It would be nice to have some analog to Python's set and dictionary
comprehension not just list comprehensions.  Maybe also a concise syntax
way for things like "argmax".

In general, I'm disappointed that Kawa moves away from prefix notation
(i.e. I will not use it these things).

Helmut

Re: list comprehension patterns

[Per Bothner]

On 05/19/2017 08:38 AM, Helmut Eller wrote:
> It would be nice to have some analog to Python's set and dictionary
> comprehension not just list comprehensions.

While Kawa has an OK hashtable API, I would like a more concise "map literal"
syntax, plus I'd like to be able to use a map as a function (i.e. using
funation call syntax, like Kawa allows for sequences).

Not sure how to do dictionary/map comprehensions but definitely worth thinking about.

I'm not convinced that set comprehensions are useful enough to be a priority.

> Maybe also a concise syntax
> way for things like "argmax".

Hm.  No brilliant ideas come to mind.  You could do something like:
(! mx (max @lst))
(! argmaxes ;; all max indexes
     (let (([i ...] [0 <: (length lst)]))
       [(if (= (lst i) mx) i) ...]))
(! argmax (argmaxes 0)) ;; first max index

That is obviously pretty klunky.
> In general, I'm disappointed that Kawa moves away from prefix notation
> (i.e. I will not use it these things).

If you're referring to the postfix '...' operator, that is a little non-Scheme-y - but
it is taken directly from R5RS syntax-rules.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: list comprehension patterns

[Per Bothner]

On 05/17/2017 04:31 PM, Sudarshan S Chawathe wrote:
> Minor point: I found the comparison of outer-product to a database's
> "outer join" confusing.  If I'm not mistaken, the operator is more like
> a database's cross product (or "cross join").

On 05/18/2017 03:58 PM, Andrea Bernardini wrote:
> I think what you call outer join should be called Cartesian product
> or cross join

Thanks to both of you - I changed it accordingly.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: list comprehension patterns

[Per Bothner]

On 05/18/2017 03:58 PM, Andrea Bernardini wrote:
> Quite interesting article, I found some minor typos/issues
> 
> * Where you say Kawa-specific "|" do you mean Kawa-specific "!" ?
> 
> * There is a repetition in this sentence "A "scan context" is is an expression"
> 
> * "and then result sequence is "spliced" into its context." You meant
> "and the result"?

Oops.  Fixed.

> * Another repetition and the sentence is not completely clear "When in
> the scope of two more more distinct scan variables then are scanned
> "in parallel""

Re-phrased.

> Regarding the hypothetical filtering syntax
> 
> (! [a ...] A #!if (P a))
> 
> what about using one of 'when', the first is inspired by the single
> branch if in Racket (where the 'if' keyword is replaced by when).
> 
> (! [a ...] A when (P a))
> 
> Also 'where' or 'on' could be possibilities.

Yes, those are all possible.  Note that Scheme generally does not use
identifiers this way, with rare exceptions (such as 'else' in 'case').
We also have to be careful about parser ambiguities, as well as robustness
when it comes to errors.

I think the decision will come down to what filtering syntax
works best with cross product.

> The ellipsis syntax is nice, however when more scan patterns are
> nested together can be confusing, have you considered using two dots
> instead of three
> 
> #|kawa:31|# (define (fun2 [[x ..] ..] [y ..])
> #|.....32|#   [[(+ x y) ..] ..])

I don't think that helps any.  The key thing to note is that we're using '...'
*exactly* the way '...' is used in R5RS syntax patterns and templates
(except not in a macro-definition context, of course).  So using '...'
makes a lot of sense.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/