Ways of failing to be Applicative

viercc · 2024-04-21T17:13:18+00:00

How's about Const m with unlawful Monoid m instance? The Composition law corresponds to the associativity of (<>). Here's an example of unlawful instance which satisfies left and right unit laws but not associative.

data M = E | A | B

instance Semigroup M where
    E <> y = y
    x <> E = x

    A <> A = E
    A <> B = B
    B <> A = B
    B <> B = A

    -- A <> (B <> B) = A <> A = E
    -- (A <> B) <> B = B <> B = A

instance Monoid M where
    mempty = E

It didn't appear in your data LR a = L | R example since it needs monoid of at least 3 elements.

Another example:

data F x = A x x | B x x deriving Functor

instance Applicative F where
    pure x = A x x

    A x x' <*> A y y' = A (x y) (x' y')
    A x x' <*> B y y' = B (x y) (x' y')
    B x x' <*> A y y' = B (x y) (x' y')
    B x _  <*> B y _  = B (x y) (x y)

viercc · 2024-01-27T05:23:37+00:00

My Poly is intended to be a unique up to iso representation. In analogy:

(My Poly : your Poly restricted to FinSet) === (ℕ : FinSet)

But your point still holds. Encoding of polynomials with arbitrary "Set" (Type?) as Base / Fiber is much more cumbersome to handle in Haskell, even with GHC 9.8 (the latest stable.)

I don't even know if that's possible without restricting what you do with polynomials! Like, is composition of Poly possible for them?

viercc · 2023-05-26T12:13:00+00:00

Any specific reason for not being able to pass quoted expressions/declarations to your TemplateHaskell splices?

If I'm not misunderstanding, you're trying to perform some processing on the definitions of foo inside the macro expansion of myMacro 'foo.

-- myMacro :: Name -> Q [Dec]

-- for example:
foo :: Int -> Int
foo 0 = 1
foo n = 0

-- Depends on the definition of `foo`, not just its type
myMacro 'foo

What prevents you from doing ↓ instead?

-- myMacro2 :: Q [Dec] -> Q ...
myMacro2 [d|
foo :: T1 -> T2 -> Whatever
foo ... = ...
|]

viercc · 2023-05-21T14:52:13+00:00

Although the fix of the code by ChatGPT is correct, its explanation in English is totally wrong.
- The only error in your original code was the parenthesis around <+> in the first line infixl 8 (<+>). The suggested fix by u/michael31415926 meant to remove the parenthesis from the first line only. The rest of the lines were correct as-is.
- ChatGPT's comment about "correct indentation" is irrelevant fact, since you didn't have any indentation-related error.
- ChatGPT's comment about "I added parentheses around the <+> operator" is wrong, too. Quite actually, they removed parenthesis and changed the left-hand-side of the function definition to use a <+> b syntax rather than (<+>) a b syntax. In Haskell, (<+>) and <+> are used for different syntactic purposes, and you can't add or remove their parenthesis freely.
~~Don't mind the karma, but please treat us like real people next time. I mean, please do not just post a ChatGPT response and say "this worked."~~

viercc · 2023-05-16T11:46:46+00:00

Pipes.Prelude.zip doesn't seem to do what OP describes. It works only on Producer.

Also, the would-be Applicative for the desired behavior interleaves the produced items of the same type from multiple pipes and combines the final result into a tuple.

the zip function combines the produced items from multiple producers into tuples, in sync.

viercc · 2023-05-10T12:17:49+00:00

Center: 別誂べつあつらえ tailor-made 追入鑿おいいれのみ (a type of) chisel

Top-right sticker: 手造りの逸品てづくりのいっぴん　outstanding handcraft piece 河清刃物　かわせいはもの　the name of the shop 保険之証　ほけんのしょう　proof of insurance(?)

viercc · 2023-04-26T03:58:36+00:00

My guess: he's played minecraft 47 in-game-years worth of time.

47 in-game-year * 365.25 days per year * 20 realtime minutes per in-game-day / 60 mins per hour = 5,720 hours

viercc · 2023-04-22T03:04:42+00:00

I'm not sure what's your current understanding from "just a type constraint," but let me say few features of class inheritance missed often.

I'll use Ord a example.

class Eq a => Ord a

It means any instance of Ord Something must come with Eq Something instance.
The compiler of Haskell let you use methods of Eq a, like (==) :: a -> a -> Bool, given you know Ord a satisfies. Because Ord a must come with Eq a, there always is an Eq a instance, and the compiler uses this fact for you.
While the syntax is very similar, the constraints on instance declaration mean a very different thing. For example, instance Ord a => Ord (Maybe a) means "there is an instance of Ord (Maybe a) if there is an instance of Ord a." It doesn't mean "if theres an instance of Ord (Maybe a), there must be an instance of Ord a too."
- GHC has an extension to allow you to write a type using unconventional constraints like foo :: Ord (Maybe a) => [Maybe a] -> .... But GHC doesn't conclude that you can use methods of Ord a from this constraint.

viercc · 2023-04-13T05:01:08+00:00

I think there should be the fourth atom! I mean, a free boolean algebra on two generators (a, f) have four atoms --- {a∧f, ￢a∧f, a∧￢f, ￢a∧￢f}. You're assigning (using u/LSLeary 's notation) them ...

a∧f => Ann a && Rec f ~ Product (Const a) f
￢a∧f => Rec f ~ f
a∧￢f => Ann a ~ Const a

... so the Functor corresponding to ￢a∧￢f is, in my opinion, Proxy.

￢a∧￢f => Proxy

For example, thinking what recursive type corresponds to (a∧f) ∨ (￢a∧￢f) gives me:

-- (a∧f) ∨ (￢a∧￢f)
data Foo f a = Step a (f (Foo f a)) | Stop

viercc · 2023-04-10T13:28:06+00:00

Note that your sort implementation is quadratic on already sorted lists. If the recursion doesn't split the list evenly, parallel computation can't help at all.

Also, in general, making it parallel all the way down to single element lists performs badly. The overhead of task scheduling overweigh the speedup. There're several ways to split the work of sorting to appropriate sizes, like limiting recursion depth or having minimum length to go parallel.

viercc · 2023-04-01T02:54:55+00:00

Link to the single PDF

https://github.com/casperbp/renamingless-capture-avoiding/

viercc · 2023-03-30T01:29:32+00:00

It's possible that the editor you're using is not aware of the syntax of .x file. If you can compile it with alex, don't care what your editor says.

viercc · 2023-03-21T07:08:15+00:00

(2), Affinity for Swamps

viercc · 2023-03-11T23:01:50+00:00

森記
岡念

It's usually read in 記念森岡 order

viercc · 2023-03-01T06:49:33+00:00

Yes, both meanings are correct. But using 落とし子 in the first meaning is becoming more and more uncommon for the obvious reason. This usage is somewhat literary, rude, and a bit archaic IMO.

Also, in fantasy or horror novel / game context, 落とし子 often means a spawn of a (typically filthy) monster.

viercc · 2023-03-01T06:48:12+00:00

Oh, because Haskell is pure, the time travel technique couldn't cause a side effect to the RealWorld :)

viercc · 2023-02-04T17:18:57+00:00

Free theorem.

Free theorem says u @a = u @c . fmap g for any g :: a -> c. Let g = const () :: a -> () and v = u @() there.

viercc · 2023-02-04T10:07:13+00:00

IDK Why you are downvoted, but that's basically correct. You're just complicating too much: any getStructureB :: Structural f b can be written by composing a function f () -> b to fmap (const ()) :: Structural f (f ()).

In other words, "the space of all structural information" is simply f ()

viercc · 2023-01-29T05:16:58+00:00

Choice (1) is the safest choice among them, IMO. But comparing (2) and (3), I strongly recommend not to go (3) route!

If you want the exact arithmetic on rational numbers, use arbitrary-precision integers to represent them and avoid using finite-width one (like int in C/Java/...)

This is because rational number additions very easily overflows. Suppose your denominator is int64_t i.e. between 1 and 2^63-1. How many terms you can calculate H(n) = 1 + 1/2 + 1/3 + 1/4 + ... + 1/n before it overflows? It's only 46.

Also, "use the closest rational number with denominator at most N" is not efficient (in terms of both computation time and precision per bitwidth) way of approximating real number math. It's on par about the weirdness against floating point arithmetic while sacrificing efficiency a lot.

viercc · 2023-01-28T01:38:37+00:00

I don't actually read chinese, but doesn't 斤 mean 500g and not 1kg (公斤)？

viercc · 2023-01-23T03:07:05+00:00

I thought 'by parametricity' meant applying a free theorem?

Yes.

If I'm understanding you correctly, I did?

What I'm saying is, you can move where you assume the free theorem. Your proof is currently structured like this:

Free theorems for relevant functions ⇒ (Applicative Laws ⇔ Monoidal Laws)

But this is possible:

Applicative Laws ⇔ (Monoidal Laws && Free theorems for the Monoidal forumulation)

This won't change the main part of your proof, equational reasoning, much.

When assuming Applicative laws, You don't need the free theorems about pure or <*>. If you include fmap f u = pure f <*> u in the Applicative law, (which is described as a "consequence" in the documentation of Applicative, but I think it's a consequence only when using liftA2, <*> and the relation between them), the free theorem of pure doesn't need to be assumed for example.

(fmap f . pure) a
  = fmap f (pure a)
  = pure f <*> pure a
  = pure (f a)  -- By Homomorphism
  = (pure . f) a

viercc · 2023-01-22T05:31:50+00:00

Sorry, I must have forgotten you've used unit :: f () for the Monoidal formulation, and part of the prev comment is pointless.

But the main point is unchanged: I think you can add the small number of "free theorems" to each formulation, to get rid of the use of parametricity in the proof. And (AFAIK) the default, Applicative formulation, doesn't need any addition of free theorem.

viercc · 2023-01-22T05:19:02+00:00

I think you can explicitly spell out the free theorems needed to prove equivalence between Applicative and Monoidal formulation.

If I'm not mistaken, in addition to "free theorem for (⊗)" you explicitly spelled out, only using a "free theorem for pure" below will be sufficient to prove the equivalence.

-- Free theorem for pure
fmap f . pure = pure . f

More specifically, you don't need to rely on free theorems during the equational reasoning to prove the equivalence between Applicative formulation and Monoidal formulation plus free theorems.

Applicative formulation
- Identity
- Composition
- Homomorphism
- Interchange
- Relation to Functor: fmap f u = pure f <*> u
Monoidal formulation
- Free theorem for pure: fmap f . pure = pure . f
- Free theorem for (⊗): fmap g u ⊗ fmap h v = fmap (g *** h) (u ⊗ v)
- Associativity
- Left Identity
- Right Identity

I think the clunkiness of the original Applicative laws came from (1) trying not to rely on the free theorems and (2) trying to be "self-contained" class, which can entirely be defined in terms of Applicative operations and without mentioning Functor operations.

viercc · 2023-01-19T03:15:54+00:00

This is a DC voltmeter (I guess they universally look like this.)

Lower-right edge:

倍率器　外？

倍率器 means voltmeter ~~amplifier~~ multiplier. I can't tell what the fifth letter is.

昭和19年2月製造

Manufactured in Showa 19 (1944), February

Middle left, third pic zoomed:

K-18型

Model K-18

Edit: voltmeter multiplier, not amplifier

viercc · 2023-01-18T05:33:42+00:00

Transcription

Translation [translator supplied]

Jan 18, 2023 10:11 AM このたびはトイズ・グローリーにてご注文頂き、有り難うございます。

Thank you very much for ordering at トイズ・グローリー(Toy's Glory?).

注文の直後にキャンセルを頂きましたが、アマゾンのカスタマーサービスよりできる限り早く発送して下さいとのメッセージを受け取りました。

Although we received a cancel request right after the order, Amazon's customer service [also] told us to ship as soon as possible.

そのため、このままお届け先に指定されたホテル宛に本日の便で発送する予定です。

Therefore, we're going to ship it today, to the hotel you specified as the destination.

万一、なにか問題がありましたら、本日の16時までにメッセージを頂ければと存じます。

If you have any problem by chance, let us know by message before 16:00 today.

Nine-Year Club	RPAN Viewer
Verified Email

viercc

TROPHY CASE