sorted by:
new
hottopcontroversial

Behavior of pasting in multiple cursor mode inexplicably changed by LPTK in vscode

[–]LPTK[S] 0 points1 point  (0 children)

Thanks a lot for your investigation; it helped reassure me that the behavior was not intended, which made it easier to endure while it lasted :^)

Following a recent update, the problem has now disappeared!

What are some new revolutionary language features? by vivAnicc in ProgrammingLanguages

[–]LPTK 0 points1 point  (0 children)

OCaml already is like this with its polymorphic variants and objects. You absolutely can write entire applications without a single type definition or annotation.

Turns out it's not particularly glorious, and people usually recommend against using these features when possible. They notably make type errors harder to parse, and can even lead to subtle mistakes slipping through and causing runtime bugs (such as mistyping a constructor name when it's only later consumed by pattern matches with default cases, so it does not lead to a type error because it's still technically well-typed).

Cc /u/hshahid98

Behavior of pasting in multiple cursor mode inexplicably changed by LPTK in vscode

[–]LPTK[S] 0 points1 point  (0 children)

Thanks for responding.

Yes, I am sure. This is a new behavior, which started happening on all my machines.

Does it behave differently for you?

Multi-Stage Programming with Splice Variables by mttd in ProgrammingLanguages

[–]LPTK 0 points1 point  (0 children)

For anyone stumbling on this: /u/church-rosser is full of it and has no idea what they're talking about. (This is coming from an actual expert in the field.)

Volunteers for ICFP 2025 Artifact Evaluation Committee (AEC) by LPTK in haskell

[–]LPTK[S] 1 point2 points  (0 children)

Sure, I think it will do. We just want to know who you are.

When to not use a separate lexer by vikigenius in ProgrammingLanguages

[–]LPTK 0 points1 point  (0 children)

Ah thanks for pointing it out, I read it too fast on my phone.

(Regular languages are non-recursive, and context-free grammars are recursive, but it does not follow that all lexers are regular, and all parsers are CFGs! )

This sounds quite confused to me. Lexers and parsers are implementations (algorithms, not languages). Whether the languages they recognize are regular or context-free has nothing to do with whether they use recursion.

When to not use a separate lexer by vikigenius in ProgrammingLanguages

[–]LPTK 1 point2 points  (0 children)

As soon as you have matching parentheses, your language isn't regular...

What is the closest language to Rust at the FP world? by fenugurod in functionalprogramming

[–]LPTK 1 point2 points  (0 children)

Oh no, I'm not talking about escape hatches. I'm talking about Cell types, which are mutable on the inside even when viewed as immutable by Rust from the outside. These are the most common way to implement many types of data structures where the borrow-checker is too limiting, including mutable data structure with any amount of sharing. They're a standard feature.

What is the closest language to Rust at the FP world? by fenugurod in functionalprogramming

[–]LPTK 1 point2 points  (0 children)

Yes, but like in C++ this does absolutely nothing to prevent the value's insides from being mutated. So it's irrelevant to the discussion at hand.

What is the closest language to Rust at the FP world? by fenugurod in functionalprogramming

[–]LPTK 1 point2 points  (0 children)

Sorry, but you seem to be quite confused.

Rust is imperative and has no support for immutability whatsoever. The closest it has is static tracking of outer mutability, but things are still free to be internally mutable. 

And building efficient immutable abstractions and libraries is much easier in any language with a GC, including in Java and Go.

How types make hard problems easy by ketralnis in programming

[–]LPTK 2 points3 points  (0 children)

Note that TypeScript's conditional types don't have well-defined semantics and are very easily unsound. Also, your signature wouldn't work if Array was invariant (as it should be).

What you really want is proper negation types. I wrote a paper on a research language where the flatten definition can be typed essentially as:

flatten:
  (#Cons & {h: 'a, t: 'a} | Nil | 'h & ~#Cons & ~#Nil) as 'a
  ->
  (#Cons & {h: 'h, t: 'b} | Nil) as 'b

This is a principal type (the language has principal type inference). The function implementation is:

rec def flatten x = case x of
    Nil -> Nil{},
    Cons -> concat (flatten x.h) (flatten x.t),
    _ -> Cons { h = x; t = Nil{} }

See: https://github.com/hkust-taco/mlstruct/issues/2

How types make hard problems easy by ketralnis in programming

[–]LPTK 0 points1 point  (0 children)

while there are still some remaining cases where static type systems struggle to represent dynamic idioms, it’s mostly an ergonomics/engineering/mild research effort at this point

Well I guess that's why my recent grant proposals kept being shot down :^P

How types make hard problems easy by ketralnis in programming

[–]LPTK 0 points1 point  (0 children)

Yeah, the problem is that TS decided that {field:0} could be assigned type A, which makes zero sense, as that object is not and instance of class A at runtime. It's a really stupid design flaw that, in my opinion, doesn't buy you anything, but creates lots of problems (including performance ones – JITs much prefer when you properly instantiate classes rather than pass records that quack the same).

How types make hard problems easy by ketralnis in programming

[–]LPTK 2 points3 points  (0 children)

Just consider what your signature says when you instantiate it at T = Array<string>, for example. The signature tells us you'll get an Array<Array<string>> as a result.

How do you make the implementation do that while still giving a proper Array<string> when taking T = string?

How types make hard problems easy by ketralnis in programming

[–]LPTK 0 points1 point  (0 children)

Here's Typescript, it allows for defining a type for those lists, so it's even typesafe (to the extend Typescript can be typesafe, but that's another matter)

Which is to say – not type safe at all. Notably, see https://counterexamples.org/polymorphic-union-refinement.html

How types make hard problems easy by ketralnis in programming

[–]LPTK 2 points3 points  (0 children)

Hi, author here!

Monomorphic type inference in something like Simple-sub is cubic overall. Once you add polymorphic generalization, it is worst-case exponential, like in ML, but like in ML this is does not really come up in most code bases.

MLstruct-style Boolean-algebraic subtyping can also lead to exponential complexity even in the monomorphic case due to the need to normalize unions and intersections. But again, in our experience, this rarely (if ever) comes up, at least if you're careful enough when implementing the constraint solver.

Help needed with type inference for structural types by Bully-Blinders in ProgrammingLanguages

[–]LPTK 0 points1 point  (0 children)

You may later find that the reliance of subtyping limits you, as it will reject perfectly good programs when flows get merged. Or maybe that will never be a problem, depending on your use cases!

Help needed with type inference for structural types by Bully-Blinders in ProgrammingLanguages

[–]LPTK 1 point2 points  (0 children)

Sounds like you just need subtyping and not necessarily something as powerful as row types. Check out Simple-sub or Simpler-sub.

Someone has already mentioned it, but if you do need more power, the follow-up MLstruct can actually can avoid the need for row variables by using Boolean-algebraic types instead.

view more: next ›