The Garbage Collector

David Young

00:20

@Delfin For the Prelude, table 2 in chapter 4 of the Haskell 2010 Report

Delfin

@DavidYoung And what is the precedence of <*> and <$>?

Unrelated String

...til that backtick infixified functions don't all have the same precedence

that's kind of horrifying

but also kind of makes sense

Michael Homer

@Delfin <*>, <$>

David Young

You can also find the precedence of an operator in GHCi using :i like this :i <*>

This will also tell you where it's defined

(and it works for non-operators as well)

Delfin

@DavidYoung Haskell does not have operators

David Young

00:34

?

what about the operators we were just talking about

Delfin

@DavidYoung They are infix functions

Michael Homer

... did you look at the Haskell Report that was linked to you?

David Young

The Haskell Report indeed calls them "operators"

This is also the term that is typically used when I've talked to other Haskell programmers. I've spent a decent amount of time on the Haskell tag on StackOverflow and in the #haskell IRC chatroom, and this is the usual thing to call them

Most of my answers are on the StackOverflow haskell tag, in fact

Dannyu NDos

Yeah; infix functions are functions that is made infix by surrounding graves (`).

Delfin

@MichaelHomer Only the table 2

@DannyuNDos I think they would better refereed as infixed functions. And we can call the operators infix functions

@DavidYoung Anyway, How are the precedence of infixeed functions defined?

Dannyu NDos

00:43

:(

David Young

@Delfin using the infixr and infixl keywords

and infix

Delfin

@DavidYoung But it would not make them infix all the time except when they are like (+)

?

David Young

What do you mean?

Seggan

@Delfin i meant ==/!=

Delfin

@DavidYoung That If I write something like infix myFunction, then myFuntion arg1 arg2 is invalid but arg1 myFunction arg2 and (myFunction) arg1 arg2 are valid

David Young

00:55

@Delfin Operator names can only consist of non-alphanumeric characters. When you use one of the infix keywords with a regular function name, it applies to the backtick infix syntax and nothing else

(also, we see here a good reason for distinguishing between "operators" and "non-operators". The language itself makes that distinction)

Dannyu NDos

Does anyone know why GHC doesn't define instance Monoid e => Alternative (Either e)?

David Young

01:11

@DannyuNDos I'm guessing the reasoning is something like: It's kind of strange to just use the Monoid constraint for mempty and most of the time you should probably use the Maybe instance for Alternative if you want to do this

Delfin

03:37

@Seggan And is what I assumed to mean

Can you express all the PostgressSQL, GraphQL, Rest and so on in Datalog?

Also document database queries and so on?

Michael Homer

04:00

I’m not sure what that means

What are you (conceptually) trying to do?

Delfin

Can every Query written in SQL (MariaDB, MemSQL, PostgreeSQL), GraphQL, Rest, EdgeQL (docs.edgedb.com/get-started/edgeql) be written in Datalog?

@MichaelHomer Conceptually I am trying to "replace" all query protocols of both SQL an non-SQL databases with Datalog.

Michael Homer

Many RDBMS dialects support unbounded loops, so probably not

Maybe you could simulate that for practical cases in Datalog but I am sceptical of it

Delfin

@MichaelHomer No need to be a problem, either We get a dialect of datalog with added unbounded loops for those case, or it can simply left unsupported (As really is no to replace all with datalog). But most important what would be lose if we remove unbounded loops?

Michael Homer

04:18

It’s no longer supporting every query, but I don’t think I’ve ever written a real loop within SQL personally

Delfin

@MichaelHomer As long nothing important is lose. Is just fine

Dannyu NDos

06:00

CMP: Do you call the design pattern "facade" or "façade"?

Dannyu NDos

06:30

Design Patterns

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk. It has been influential to the field of software engineering and is regarded as a...

I gotta read this

Delfin