Please have a look at brick-tabular-list on hackage.

[amano-kenji]

I think its documentation and its implementation can be considered finalized.

Please come have a look at brick-tabular-list, and run the demos.

It can be improved, but it's already good enough to not need modification for how long do I know?

[jtdaugherty]

@amano-kenji I'm not sure what you are looking for. Is this a request for feedback of some kind?

[amano-kenji]

Tell me any impression you get. And, if you can give me any feedback, sure. But, I am not asking you to look hard.

I want to celebrate my little wins.

[jtdaugherty]

Congrats the release! I took a brief look over the Haddock documentation. A couple of thoughts relevant to this page:

• Type aliases with type help with readability at first because they give more meaningful names to types based on context, but they harm readability in the long run because the code that uses them will just use the underlying values with no other visual evidence that the type aliases are in use. They also don't protect against mistakes made with e.g. passing arguments out of order. If you want to protect against the latter, I strongly recommend using a newtype instead. Otherwise I recommend just removing the current type aliases.
• Type variables are typically a single letter only. This helps them be more pronounceable, which is important for readability. In this case, rowH would probably just be written as r, but since your API uses many type variables elsewhere, it would be important to carefully consider a good single-letter mnemonic for all of them as a group and then be sure to use the same letters consistently across the API so that each letter has the a consistent meaning wherever it is used.

[amano-kenji]

If you want to protect against the latter, I strongly recommend using a newtype instead. Otherwise I recommend just removing the current type aliases.

With just Int types, I, the original author, was confused. So, it should be newtype if it changes. Is there an extension that automatically wraps Int in newtype? OverloadedString was very useful.

This helps them be more pronounceable, which is important for readability.

There are row and rowH type variables. If row was changed to r and rowH was changed to R, I would be confused.

I may consider changing row to r and changing rowH to rh.

I generally prefer longer names because I want to leave no room for confusion.

[jtdaugherty]

Is there an extension that automatically wraps Int in newtype?

No, but in this case you could derive Num and then be able to use numeric literals in place of your newtypes. But I would not recommend it: that defeats the purpose of both the newtypes and readability! If you're going to add newtypes (which in your library I would not recommend, because I'm not sure they add enough to justify the pain they add to the API), then it's probably best to export the constructors of the newtypes.

I generally prefer longer names because I want to leave no room for confusion.

I understand. I shared the feedback because of community conventions that are good to know about, and it's a change I'd want to make if I were the maintainer. I find that if confusion is especially likely in an API design like this, that can also mean that there are too many type variables and that a different abstraction might be better than thinking hard about better names for the (many) type variables.

[amano-kenji]

a different abstraction

I made brick-tabular-list under time pressure. I really need to produce something I can personally use in a month or two from now. My financial survival depends on it. I didn't and don't have time to come up with an elegant abstraction. It is good enough. It serves the purpose. I moved on.

Despite the time pressure, it was not sloppily designed. That was more than good enough for me.

The design can be improved, but it is already clean enough at this point.

[amano-kenji]

If you're going to add newtypes (which in your library I would not recommend, because I'm not sure they add enough to justify the pain they add to the API

You are right. I doubt that newtypes add enough value to my API. It is going to be more painful to use newtypes. It is going to break backward compatibility. My library is not big enough to really benefit from newtypes.

Next time I design a new library, I may consider newtype.

[jtdaugherty]

I made brick-tabular-list under time pressure. I really need to produce something I can personally use in a month or two from now. My financial survival depends on it. I didn't and don't have time to come up with an elegant abstraction. It is good enough. It serves the purpose. I moved on.

For what it's worth, I sense some defensiveness here, and if that's true then I wanted to clarify that my feedback isn't intended as a criticism of the approach taken in your library. It's feedback on how I think about it, which is, after all, what you asked for. :) You can take it or leave it and perhaps consider it next time you are working on something.

[amano-kenji]

the approach taken in your library

The approach is to move fast without breaking my neck or being sloppy because sloppiness also costs time. The design you see is just that.

For now, if it's not broken, I won't touch it. In months, I may or may not have time to come back to the design. At least, it's not a dirty design. I can later improve a design that's not dirty or broken.

When I worked as a paid programmer, I saw dirty design that was beyond repair.

Just a roundabout way to say I'm in a hurry. I appreciate that you took time to have a look. It's just that you feel the pressure I'm in. For now, any feedback will be weighed against the amount of time I have. If I didn't have to write a software, I wouldn't.

[amano-kenji]

With everything said, sure, I want to explore newtype and less type variables if I have time later.

[amano-kenji]

To be honest, I thought it was going to be very difficult to eliminate type variables because I couldn't figure out a way to improve it while I was implementing it for the first time.

But, because you mentioned it, I briefly re-examined brick-tabular-list. I quickly realized that I could replace

XXXTabularList n row cell rowH colH

with just

XXXTabularList n e

The API could be simplified greatly. The type variable t in GenericList n t e is fixed to Seq in my tabular list widgets because Vector is slow to update, and Seq is reasonably fast for searching and updating.

It seems that an hour of work in flow state full of energy can be more productive than 100 hours of tired grind. In general, if you are grinding and tired, it is not right. My aim is to do more work in flow state in order to speed things up instead of grinding more. You cannot beat flow state with grind.

I considered newtype, but the API is simple enough that it seems very unlikely to make mistakes without newtype. If I get confused with types of function parameters, I may consider newtype.

[jtdaugherty]

The API could be simplified greatly.

What a great discovery!

It seems that an hour of work in flow state full of energy can be more productive than 100 hours of tired grind.

I have also found this to be true. And taking a break from what you're working on and coming back to it later can easily provide a fresh perspective where you might notice things that you didn't before - bugs, but also better design ideas, etc. Our brains have a habit of continuing to "work" for us even when we are not actively focused on a thing, and it can be nice to put that to good use.

[amano-kenji]

After experimenting with newtypes, I realized newtypes make implementation infinitely more redable. Thus, I replaced all type alises with newtypes.

Now, people can actually read and understand implementation.

With newtypes, demo programs are much more redable, too.

Now, the API is simple and easy to understand. Before 1.0.0.0 and 2.0.0.0, the API and the implementation were a bit ugly and difficult to understand.

brick-tabular-list-2.0.0.0 is excellent. It almost seems perfect. If it is perfect, it hopefully won't need breaking changes in the next few decades.

A challenge with newtype was to devise good abbreviated names for newtype constructors and make newtypes that match library concepts.

I think I can say brick-tabular-list is really finalized.

I told you I would tackle tabular list problem until it is done. This is the power of strong intention.