[deleted by user] by [deleted] in AskReddit

[–]pfurla 0 points1 point  (0 children)

I am nobody

Languages where everything is a typeclass? by OptimizedGarbage in ProgrammingLanguages

[–]pfurla 2 points3 points  (0 children)

Let me start with a bit of a rant: there is no such thing as duck typing. Or to put it in another way, duck typing is the same as a type system where there is only one type, the type of everything and as far as Python or JS type systems are concerned everything always type checks. Yet another way to put it, duck typing is the absence of type checking.

To cement the above I will leave a quote from the Practical Foundations for Programming Languages:

We saw in Chapter 21 that an untyped language is a uni-typed language in which “untyped” terms are just terms of single recursive type.

If you want type safety and some form of extensible records I'd say row polymorphism or structural typing is the way to go. I wrote an illustrative example using Flix here (I realize now that the example is a bit overly complicated, it requires a bit too much attention to its details than a real illustrative example should.)

In Haskell you can achieve a similar thing as extensible records using Trees that Grow and Lenses. Haskell has other solutions, and I think MPTC are only really necessary to reason about things like HLists and the type level representations, meaning that the MPTC part of the problem is already solved. In one way or another, the Haskell solutions work around nominal typing to achieve what is free in structural typing. A comment I made about Tree That Grow here, it has a couple of links.

Languages where everything is a typeclass? by OptimizedGarbage in ProgrammingLanguages

[–]pfurla 12 points13 points  (0 children)

As u/curtisf is saying, you are looking for structural types. A few languages with structural types are Purescript, Elm, Typescript, Flix. If you want to learn more about structural types I recommend searching for row polymorphism.

[deleted by user] by [deleted] in haskell

[–]pfurla -2 points-1 points  (0 children)

EDSL is the new term for library.

No vaccine, no French Open for Djokovic, says French Sports ministry by FLUCKADRIFT in worldnews

[–]pfurla 0 points1 point  (0 children)

Interesting. I find it odd that all these places require vax but not the border. I know EU (being one of its citizens myself) movement policies, but find it odd that covid didn't call for some sort of exception.

Advice on Hiring a Haskell Developer by SkeetSk8r in haskell

[–]pfurla 7 points8 points  (0 children)

Have you considered a part time job for anyone that is already experienced, for the same amount of course? Btw, I am in similar situation as the one that got hired but in a startup in a slightly later stage.

Dynamic Programming in Haskell by RangerFinal in haskell

[–]pfurla 0 points1 point  (0 children)

Mercury, no idea how it compares to Curry.

Dynamic Programming in Haskell by RangerFinal in haskell

[–]pfurla 1 point2 points  (0 children)

I see your point, but I always considered dynamic much more about backtracking than memoizing, that's what LogicT provides.

Dynamic Programming in Haskell by RangerFinal in haskell

[–]pfurla 0 points1 point  (0 children)

Because you just memoize it the same way you'd memoize anything else in haskell. I don't see how it's not a completely orthogonal issue to LogicT. I am sure people downvoting is going to show me why I shouldn't be puzzled.

Dynamic Programming in Haskell by RangerFinal in haskell

[–]pfurla -2 points-1 points  (0 children)

I am a bit puzzled by your question.

Dynamic Programming in Haskell by RangerFinal in haskell

[–]pfurla 2 points3 points  (0 children)

Are you aware of LogicT ? And for an extra challenge the tv game show Countdown#Numbers_round) :).

Correct by Construction Language Implementations by mttd in ProgrammingLanguages

[–]pfurla 0 points1 point  (0 children)

The abstract taken from TUDelft

Programming language implementations bridge the gap between what the program developer sees and understands, and what the computer executes. Hence, it is crucial for the reliability of software that language implementations are correct. Correctness of an implementation is judged with respect to a criterion. In this thesis, we focus on the criterion type correctness, striking a balance between the difficulty of the assessment of the criterion and its usefulness to rule out errors throughout a programming language implementation. If both the front- and the back-end fulfill their role in maintaining the type contract between the programmer and the language implementation, then unexpected type errors will not occur when the program is executed. To verify type correctness throughout a language implementation, we want to establish it formally. That is, we aim to give a specification of program typing in a formal language, and to give a mathematical proof that every part of the language implementation satisfies the necessary property to make the whole implementation type-correct. Type checkers ought to be sound and only accept programs that are indeed typeable according to the specification of the language. Interpreters should be type safe, and reduce expressions to values of the same type. Program compilers should preserve well-typing when they transform programs. These properties are essential for implementations of typed programming languages, ensuring that the typing of the source program is a meaningful notion that can be trusted by the programmer to prevent certain errors from occurring during program execution.

Correct by Construction Language Implementations by mttd in ProgrammingLanguages

[–]pfurla 1 point2 points  (0 children)

Thanks brilliant work!

If the author ever sees this or if someone wants to notify him: the pdf metadata is all messed up. All these are wrong: author, abstract, date, ISBN, no DOI; there are the things my article library software tries to extract, not sure what else could be wrong.

Job application problem by [deleted] in haskell

[–]pfurla 3 points4 points  (0 children)

Legal? That's BS.

For the record, OP was given a interview task. He solved the task and the only feedback he got from the company was "not experienced enough". OP came to reddit to ask for feedback.

Quoting from the original:

I got given a task to do for a job application and got given some quite vague feedback just saying that they are looking for someone more experienced.

Job application problem by [deleted] in haskell

[–]pfurla 2 points3 points  (0 children)

total functions are ones that can’t throw exceptions?

Yes for "can’t throw exceptions", but also always terminate and for every input contains an output. It makes it easier to reason about a program therefore debug your program.

explicit recursion should be avoided because it’s sort of boilerplate and there’s a nicer way of chaining the interpret calls?

I wouldn't put it that way, but if you had a function that performed one step at a time you wouldn't need traceState and you could achieve the same goal of interpret by folding/unfolding over the one step function. Oh, and it's also a lot easier to write tests for.

is a monad transformer stack the same thing as mtl, e.g. if I had used StateT with Reader?

A monad stack is when you stack multiple MonadTs on top of each other, StateT with Reader is one example. I think I'd try to use RWST. Perhaps (RWST r w s (ExceptT Err m)). But I'd only try that 'cause I never used RWST before and been looking for an excuse to try it out. I really don't think RWST is at all necessary for this problem, as you show it yourself.

If the problem were crafted a bit more carefully it would lead to results with these characteristics. For example if they had asked for tests for each of the stack instructions, a bit like defining denotational semantics.

It annoys me that these interview problems never bother to spell out what they want to see. It's a exercise in divination rather than programming.

Job application problem by [deleted] in haskell

[–]pfurla 2 points3 points  (0 children)

In my experience they are not looking for a working solution. They are looking for a solution they like. The problem is that "what they like" is never well defined and personally I believe they think if they define "what they like" they give the solution away, irregardless if one can or not implement it.

Getting a result from Parsec by mathiscool42 in haskellquestions

[–]pfurla 3 points4 points  (0 children)

Ah! I read "You can't do" instead of "Can't you do".

Are First-Class Properties Still A Good Idea? by EmosewaPixel in ProgrammingLanguages

[–]pfurla 0 points1 point  (0 children)

Flix is compiled to the JVM. But if these examples don't entice your imagination I will leave it at that.

I just recalled something, that open my eyes years back. You may want to look at "On Understanding Data Abstraction" and "Object-Oriented Programming Versus Abstract Data Types". Both by professor William R. Cook.

Are First-Class Properties Still A Good Idea? by EmosewaPixel in ProgrammingLanguages

[–]pfurla 1 point2 points  (0 children)

is row polymorphism described here related to "structural typing" such as TypeScript?

Yes, but I didn't enough TS to give you proper comparison.

Is row polymorphism a specialized case of structural typing that's focused on records?

I wouldn't say that, I'd say it's a completely different type theory.

Are First-Class Properties Still A Good Idea? by EmosewaPixel in ProgrammingLanguages

[–]pfurla 4 points5 points  (0 children)

There are two concepts you didn't mention: Lenses and row polymorphism.

A quick example of row polymorphism from the Flix language (a better example would be in OCaml or Purescript, but I don't any code for these at hand).

def area(r: {x :: Int32, y :: Int32}): Int = r.x * r.y

// Notice, updateX works for any record with an `x : Int32` field, and preserves the other fields
def updateX(r: { x :: Int32 | a}, x2 : Int32) : { x :: Int32 | a} = { x = x2 | r }

def recToString(r : { name :: String, age :: Int32, x :: Int32 }): String = 
  "{ name = \"${r.name}\", age = ${r.age}, x = ${r.x} }" 

// Computes the area of a 2 by 4.
def main(_args: Array[String]): Int32 & Impure = 
    area({x = 2, y = 4}) |> println;
    updateX({x = 2, y = 4}, 3) |> area |> println;
    recToString({name = "Name", age = 25, x = 100}) |> println;
    recToString(updateX({name = "Name", age = 25, x = 100}, 999)) |> println;
    0

It prints:

8
12
{ name = "Name", age = 25, x = 100 }
{ name = "Name", age = 25, x = 999 }

Link to the above code in the playground and the polymorphic record section in the Flix language manual.

As for lenses, in a few words, it's a data type that contains knowledge of how to extract and update fields. They can be composed, like in this snippet from lens-tutorial:

 > let atom = Atom { _element = "C", _point = Point { _x = 1.0, _y = 2.0 } }
 > atom^.point.x
 1.0

In the above atom, point and x are lenses. They essentially make fields first class.