Syllabus: August update

[colinleach]

This is an update to issue #956. Two months on, there has been some progress (despite a subjective sense of wading through molasses!)

• Both dates-times and regular-expressions are now live.
• Three new concepts are now live(ish), but still need exercises:
  • multi-dimensional-arrays : no idea of what exercise to use.
  • comprehensions: PR Boutique Suggestions concept exercise [DRAFT] #992 is a draft which might fit with a bit more work.
  • higher-order-functions: no clear idea of an exercise, but might something inspired by Boutique Suggestions concept exercise [DRAFT] #992 also be developed to fit here?

At an earlier stage:

• linear-algebra has a part-written concept that is getting very long. I need to finish that before worrying about an exercise.
• dict-functions is at an early stage of doodling, to see how python/mecha-munch-management could be translated to Julia.

Interfaces

There was some discussion about this in the context of iterators.

• For an iterators exercise, we have two to play with. I'm currently at an early stage of thinking about them.
• python/plane-tickets
• julia/old-fibonacci iterator

The Julia docs list several other interfaces. Are any of these important enough for an Exercism syllabus?

• Indexing
• Abstract Arrays
• Strided Arrays
• Customizing broadcasting
• Instance Properties
• Rounding

Documents

Reports of typos have become rare recently. I suspect we wore students down, rather than making everything typo-free!

References needs improving:

• Cross-links to other syllabus Concepts (now that most of them exist).
• Add more links to relevant bits of Wikibooks.

Anything else?

[depial]

multi-dimensional-arrays : no idea of what exercise to use.

I was looking at exercism-matrix and was somewhat surprised to see that it's not in problem-specifications. For that reason, I was wondering if I should just try modifying the old one in place? I think it could use a significant rewrite since it focuses on things we weren't necessarily looking at (e.g. matrix rotations), but I'm thinking we could use the base matrix structure for something. Otherwise, we could just introduce it as a practice exercise as is and I'll come up with something fresh. I've been a bit lazy lately though...

There was some discussion about this in the context of iterators.

I'll take a closer look at the two exercises you suggest to see how they fit in with the iteration interface. My laziness again...

Are any of these important enough for an Exercism syllabus?

I think would (highly subjectively) classify Abstract Arrays as the most interesting, but I also feel Indexing and Customizing Broadcasting are potentially useful.

[colinleach]

I was looking at exercism-matrix

That was written by the previous Julia maintainers, so old-exercism-matrix is the only version.

I'll take a closer look at the various interfaces, starting with trying to get iterators done.

Also: YOU ARE AN UNPAID VOLUNTEER. "LAZINESS" WOULD BE FINE, EVEN IF IT WAS TRUE!

Unfortunately, Markdown doesn't let me put that in 28pt red.

[depial]

I'll take a closer look at the two exercises you suggest to see how they fit in with the iteration interface.

I've looked at these and I feel like:

• fibonacci iterator is purpose made for using the iterator interface (e.g. the current introduction.md is effectively just the manual section on this).
• plane-tickets appears to be aimed more at generators.

It seems Julia has these two aspects, generators and the iteration interface, which could differ from Python's idea of "iterators" in a more general sense. I found this fairly short article to be helpful in comparing the two languages.

In short, a generator (a Base.Generator type) can be created in Julia via the comprehension syntax, or Python-like generators can be created with Channels (which produces a Channel type, not a Base.Generator type).

From my current understanding, I can think of four things we could look at related to "iterators":

1. Generators from comprehensions: we've touched on in comprehensions, but this could be expanded on
2. Generators from Channels: could be part of a channel concept, or have the channel concept as a prereq.
3. Iteration interface: potentially could be part of, or related to, a broader interfaces concept.
4. Iteration utilities: things like Base.Iterators.Stateful (which provides similar behavior to a Channel).

I guess the question is what aspect of iteration are we interested in showing?

Base.Iterators has some interesting points, like lazy versions of normally eager functions (e.g. map, filter), as well as the Stateful wrapper, but I'm not sure whether that could make up a full concept or not.

The other aspects may be best left for their own concepts channels and interfaces?

With my current understanding of the landscape, I would probably recommend separate channel and interfaces concepts, where we could potentially put a generators concept after channels. There are some caveats for using Channels in the iterator interface too...

To sum up, at present, I'm not quite sure what we could put under a concept labeled iterators, with the exception of something I've suggested before: using fibonacci-iterator to guide students to using the interface without explicitly mentioning interfaces. Then, for the interfaces concept, describe interfaces explicitly, and then have the student implement a custom interface for a custom type system. I started looking into how hard it is to write a custom interface, but I got distracted shortly after starting. I feel this could be plausible though.

[colinleach]

Thank you for the analysis! I need to get back to doing more on the syllabus, after a lax few weeks. To the (limited) extent I've been doing anything, it's been messing about with Futhark, C and Kotlin. Well, I needed a temporary change of context...

[colinleach]

Apologies for the lack of progress recently. I had a fairly brief burst of activity on Kotlin, but then I got sick again. My guess is we're talking about an initial viral throat infection, which led to a bacterial secondary, and now I need to talk to someone about antibiotics. I hope to be back and engaged at some point🤞

[depial]

I hope that clears up and you feel better soon!

I've also been otherwise distracted, but mulling about some ideas for an exercise which I'll hopefully be able to put together soon.

[depial]

After reviewing the hard exercises involving structs: custom-set, rational-numbers, circular-buffer and complex-numbers, I think I would suggest adding a concept on interfaces and potentially one which expands on promotion-conversion.

• For interfaces, I think we could adapt the old concept which included the fibonacci-iterator concept exercise. This would have multiple-dispatch as a prereq and be able to take custom-set and circular-buffer as practice exercises.
• For a concept on promotion-conversion, we would need to expand on what was mentioned in the types concept (i.e. promote()) and introduce promote_rule(), promote_type() and convert(), while also potentially explaining what this does: (::Type{T})(x::RationalNumber) where T<:AbstractFloat = convert(T, x.n / x.d). This concept could take rational-numbers as a practice exercise.

For interfaces: I guess it would be best either to be as general as possible in the about.md, without mentioning specific cases (e.g. iteration, abstract arrays, etc), or to include a the two previous examples in a concise form.

For promotion-conversion: I'm not sure if there is enough for a separate concept on promotion-conversion, but what's listed above doesn't seem to be much less content than type-unions, for example, and there may be more that could be added. Another issue is that I don't know about where it should come in the syllabus:

• be a leaf from types
• be a prereq for multiple-dispatch
• have multiple-dispatch as a prereq

I'm leaning towards having multiple-dispatch as a prereq and then rational-numbers could be a practice exercise for promotion-conversion. However, it should be noted that complex-numbers can be currently listed as a practice exercise for multiple-dispatch only without the bonus_tests being activated. When they are activated, I believe they would need the proposed promotion-conversion concept (we could mention this in the instructions if needed).

[colinleach]

It just needs me to get my head together and write more concepts. I still have linear-equation-solving in progress, but far from complete. I haven't even started interfaces yet, despite months of discussion. (Plus there's the Kotlin stuff I started then stalled.)