iitalics (u/iitalics)

iitalics commented on Church-Turing Thesis Cannot Possibly Be True [video] microsoft.com/en-us/resea... · Posted by u/espeed

ghayes · 7 years ago

Doesn't computable numbers, from the reference Wikipedia article, only state they can be computed to a given nth digit? Thus, in the OP's example, the rule-and-compass construction is exact whereas the Turing machine could only approximate the number (unless given infinite time, which I assume is out).

iitalics · 7 years ago

The catch is that you can't actually measure the rule-and-compass construction with infinite precision. You can perform more operations on the construction and then measure later to verify that it produced the correct result, but so can a turing machine acting on a mere "representation" of the number.

iitalics commented on State of Multicore OCaml [pdf] kcsrk.info/slides/mcocaml... · Posted by u/systems

naasking · 7 years ago

> Ocaml already has a very mature module ecosystem and is now becoming safe and modern.

It just needs a cargo equivalent. The existing tools weren't sufficient last I checked.

iitalics · 7 years ago

OPAM and Dune (jbuilder) work very nicely IME. You don't need to touch a Makefile, you don't need to build anything by hand outside of the package manager.

iitalics commented on Tail recursion in Python chrispenner.ca/posts/pyth... · Posted by u/zweedeend

bjoli · 7 years ago

The hackyness/speed issues aside:

When compiling/transpiling/whatever between languages, I have found that relying on regular procedure calls and TCO is generally a lot simpler than having to force the looping facility of one language into the semantics of another language.

The only one I can actually imagine porting other loops to is the common lisp loop macro, but that is probably the most flexible looping facility known to man.

Edit: and oh, cool thing: racket and guile has expanding stacks and doesn't have a recursion limit other than the whole memory of the computer. This is pretty handy when implementing something like map, since you can write a non-tail-recursive procedure so that you don't have to reverse the list at the end.

iitalics · 7 years ago

To add onto the point about expanding stacks: What's especially nice about this feature is that it means that you don't need to tune your algorithms to be tail recursive when they could be expressed more clearly as non-tail recursion. Functions like map would actually be less efficient on average if it was tail recursive because you would need to re-iterate the list to reverse it.

iitalics commented on Truth from Zero? rjlipton.wordpress.com/20... · Posted by u/carlchenet

alasdair_ · 8 years ago

>did you look at the already existing playing MTG AIs: https://www.slightlymagic.net/wiki/List_of_MTG_Engines

Yes. I'm very likely going to use the guts of XMage to handle card text and encoding the game state and all legal actions. I'm deliberately trying to get a simpler version with only three cards working first so I can see if it's possible to "solve" (i.e. test every single possible action and response for every possible game and determine the optimal play each time) such a game.

A major issue is that determining what is in the opponents hand based on previous plays is pretty important in situations where such information cannot be brute forced and instead needs to rely on dependent probabilities.

>I believe exhaustively trying out all decks is not going to fly and deckbuilding should be centered around synergies + looking at what currently works (top decks).

I had decent success building a GA that could tweak the list for a simple burn deck by adding or removing single cards as a mutation. I only tested against a very simple opponent and all potential plays were hand-coded.

>I would personally settle on an AI bot that plays perfectly that I could feed decks to test.

The issue is that "plays perfectly" is an extremely tough bar (even against only one opposing deck). As a trivial example: Magic is full of "infinite" combos where a given loop can be completed an arbitrary amount of times. Knowing the "correct" point to stop the looping is extremely tough to code perfectly.

It's also possible to have, say, a trillion tokens on the board and it's legal to pick any one of them as a target - handling this kind of situation is also pretty hard to handle computationally.

iitalics · 8 years ago

>It's also possible to have, say, a trillion tokens on the board and it's legal to pick any one of them as a target

Even more entertaining, is the fact that (IIRC) there are certain combos that cause infinite loops that can't interrupted, e.g. if neither player has a counter or kill spell, then the turn lasts indefinitely.

iitalics commented on Near Future of Programming Languages [pdf] dev.stephendiehl.com/near... · Posted by u/myth_drannon

curryhoward · 8 years ago

> Languages that have dabbled with modeling effects with row types have backtracked on it in favor of IO.

Interesting. I thought algebraic effects + handlers were the new hotness in modeling effects with types.

iitalics · 8 years ago

They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.

iitalics commented on The Ergonomics of Type Checking (2016) michaelfeathers.silvrback... · Posted by u/adamnemecek

iitalics · 8 years ago

> I wish I had a language that did optional typing

> they exist, but I don't use them.

:/

The author's thoughts (I want to write dynamically to get the code working, but then make it static afterwards) are nearly the exact thing I've heard from Matthias Felleisen when he talks about the motivation behind Typed Racket.

iitalics commented on Classification of the principal programming paradigms info.ucl.ac.be/~pvr/parad... · Posted by u/jboynyc

iitalics · 8 years ago

I don't think it's possible to create a satisfying diagram like this. It's already been said, but compartmentalizing languages into "paradigms" is generally pointless.

iitalics commented on What is Hindley-Milner and why is it cool? (2008) codecommit.com/blog/scala... · Posted by u/jwdunne

iitalics · 8 years ago

Hindley-Milner is cool, but if you're planning on implementing a language with type inference, I strongly suggest you take inspiration from bidirectional type inference, notably Pierce-Turner[1] and subsequently Dunfield-Krishnaswami[2]. These algorithms are capable of inferring much more complex types and generally produce better error messages. Typically, there are very few programs which can't be typed when you combine Dunfield-Krishnaswami type inference and have the user place annotations on major function definitions.

[1] http://www.cis.upenn.edu/~bcpierce/papers/lti-toplas.pdf

[2] https://arxiv.org/pdf/1306.6032.pdf

iitalics commented on So You Want to Write Your Own Language (2014) drdobbs.com/architecture-... · Posted by u/rspivak

mrkgnao · 8 years ago

Does Racket support non-Lisp-like syntax for DSLs written in it? I've been hearing really great things about how it has the best macro system on earth, but Haskell has spoiled me to the extent that I'm a bit lazy (no pun intended at all) to look at things outside of that broad area (so Idris, PureScript, etc.) nowadays, but Racket seems to be interesting enough that (to continue the pun) I can afford a bit of IO for it.

Most of my interest stems from this excellent project in Racket that's shaping up to be quite something:

https://github.com/lexi-lambda/hackett

It uses the "type systems as macros" paper's approach to create a Haskell-like language in Racket.

(btw, I think you meant e.g., not i.e.)

iitalics · 8 years ago

>Does Racket support non-Lisp-like syntax for DSLs written in it?

Yes! You can override the reader so that it parses anything, and there are modules for writing grammers[1][2]. Still, it is usually much easier to just use the built in s-expression parser, and if you're writing a lot of lisp, you probably don't mind s-expressions anyways :)

Hackett has interested me too, I hope that progress can continue to be made, it would be a nice alternative to Typed Racket (which is great, but very complex).

I'm working with the author of the "Type Systems as Macros" paper right now, we're working on implementing a linear language (along the lines of Rust) using Racket's macro facilities and the turnstile[3] package. Being able to embed arbitrary type systems in Racket really shows the insane power of the macro system.

[1] http://docs.racket-lang.org/parser-tools/LALR_1__Parsers.htm...

[2] http://docs.racket-lang.org/ragg/

[3] https://github.com/stchang/macrotypes