Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
Haskell is easily my favorite imperative language. There's just so many tools available to express your intentions and reason about your code, even without getting into the really clever abstractions.

Also, lens is amazing.

Adbot
ADBOT LOVES YOU

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Doc Hawkins posted:

drat, what's your favorite functional language then?
C++14? :shrug:

Mostly I'm trying to make a point about paradigm availability.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
My experience in Haskell, at least, has been that purity isn't so much about never having side effects but rather quantifying them as precisely as possible, e.g. with various monads. I don't know what the idiomatic approach to that is in Closure, but if your computational task really demands mutable state that certainly doesn't mean it's poorly suited to implementation in a pure functional language.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
The Haskell Platform is pretty much deprecated in favor of Stack, FYI. It keeps things isolated and is generally a huge boon to reliability. The GTK bindings are kind of broken on Windows, and I don't think Leksah (or EclipseFP for that matter) is really very well supported in general; most people just use one of the major editors like Emacs or Sublime or Atom.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

hannibal posted:

EclipseFP is dead, the main guy stopped working on it. If Emacs is too much I'd go with Sublime, Atom or VSCode.

Also I thought the platform was using stack internally now? There was a big debate about it a few months back.
Maybe, I admit I don't follow community news very closely. I think it's pretty difficult to go wrong just installing stack directly, though. The important thing is to not be using raw cabal install.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
You've got a lot of really good points here, but it isn't any kind of coincidence that Haskell is the place where transactional memory is becoming/has become conventional.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Athas posted:

No, but transactional memory is not automatically very performant (again: parallelism is easy, efficient parallelism is not). Furthermore, another reason is probably that GHC is the most dynamic and active research compiler I know of, and run quite well by people both technically and socially competent.
Sure, but for the typical case of applications where it's not necessary to squeeze every last bit of juice out of your CPU, this represents a legitimate case where it's much easier to write correct parallel code.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

rjmccall posted:

As a former PhD student who once wrote an embarrassingly-gushing-in-hindsight essay about TM... kindof? It's very easy to write code that is obviously "correct" with TM, but that means a lot less than you might think. TM — hardware or software — tends to degrade terribly in the face of any actual contention for the memory being accessed, because of course the transaction cannot be applied if any of the memory has been touched. But even absent contention, verifying the validity of the transaction is very expensive in software implementations, and hardware implementations tend to both impose arbitrary implementation limits and add a risk of spurious rejection. This is all exacerbated by the fact that TM as expressed in systems like Haskell makes it very easy to construct enormous transactions which would require a minor miracle to actually apply in a system that isn't vastly over-specced for its load.
I'll take "easy to write something that performs spectacularly badly" over "easy to write something that silently does the wrong thing" for most projects. In my experience it's much easier to improve the performance of well-behaved but slow code than to fix broken but fast code.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Banned King Urgoon posted:

It won't, because macros and functions serve different purposes (and you should never use a macro when a function will suffice). The reason for macros is to implement new syntactic forms, with their own flow control.
This is very true. It can also be convenient to use macros to statically compile an EDSL (for example, a query language like LINQ or SQL, or URL routing rules for a REST API, or etc) to the host language.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Siguy posted:

I was talking a little out of my rear end since I didn't put much effort into learning Common Lisp, but all the built-in functions felt very old-school and weird to me, with lots of abbreviations and terminology I wasn't familiar with. That doesn't mean they're bad necessarily and I probably overstated saying they have no logic, but as someone new to the language I didn't understand why sometimes a common function would be a clear written out word like "concatenate" and other times a function would just be "elt" or "rplaca".
Common Lisp is really really old. You should probably study something modern like Racket instead.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

Lately I've been learning Idris because Haskell has a bunch of warts that make me cry. The library support is, expectedly, lacking, so I'm considering writing Haskell with an alternate prelude instead. Has anybody worked with ClassyPrelude, Protolude or Foundation who can help me decide what to use? (Or tell me if this is even a good idea, because I expect I am going to need to add a whole lot of string conversions for compatibility with libraries.)
Speaking as a one-time contributor to Idris, I too am confused about what warts you find so intolerable in Haskell. Modern Haskell is great already (ever played with lenses?), and GHC 8 is bringing all kinds of fun toys on top of that.

Idris is fun to play with, but it doesn't supplant Haskell, no matter how excited I might be about what dependent types will do for software development long-term.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Asymmetrikon posted:

I like Idris over Haskell because of some of the historical weirdness it got rid of (switching : and ::, returning Maybe instead of erroring in, i.e., List access functions, the whole Monad/Applicative thing, Int vs. Integer.) I haven't looked too much into GHC 8, though.
Last I checked Idris's Int was just as wacky as the worst-case of Haskell's, and similarly pervasive.

xtal posted:

I have a bunch of small complaints (Idris improves a lot more than the type system) but the lack of performance (String) and safety (totality) in the Prelude are what gets me. Having an opaque list type already pokes holes in type safety, so at the very least I want a Prelude that is total. Alternatives also tend to be implemented via type classes rather than concrete types which I prefer.
Text is faster than anything Idris has to offer, and [a] certainly isn't opaque! The accessors can be a bit silly, sure, but naive accessors aren't great to use anyway since they don't compose well; use lens!

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

I just wanted you to know I am really on board with lenses now. I was avoiding them because I think Template Haskell is the plague but I'm able to compartmentalize all of that junk in a Types file.
:shobon:
You don't actually need to use Template Haskell to use lenses at all, even advanced things like biplate; the boilerplate is concise and linear wrt. your original code. The TH just saves a few lines and ensures consistency, which is enough reason for me to use it, but it's by no means unavoidable. One of the original design goals of lens was actually to allow people to easily make libraries compatible with it without even depending on the package.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

So your choices are the horror of template Haskell or the horrors of boilerplate?
It takes like 1-2 lines of code to define a basic lens. If a tutorial's about using lenses rather than defining them, it's still best to skip the distraction.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

everythingWasBees posted:

As I'm finding myself using C++ and C# for everything course and research related, I'd really like to try a functional language to give myself a breath of fresh air. I'm mainly interested in making games and interactive graphical toys. Is there a language with more robust Vulkan and OpenGL support than others? Is there any that are more suited than others for games? I know you can use F# with Unity, is that a decent choice?
Are you looking to do low level or high level gamedev? OpenGL (let alone Vulkan) won't come up much in Unity.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
Nix is absolutely glorious, especially for software development, since it makes it very easy to maintain (and share!) a wide variety of different build environments with predictable versions of dependencies and tools available. Also for servers because it's a lot easier to fix/update a system that you haven't touched in two years if the entire system is described by a short stateless config file.

The language isn't great, but it's good enough. I'll take some idiosyncratic syntax over stateful package management any day.

xtal posted:

It's decently efficient. Performance is, by their admittance, not a priority. You can generate more than just C, though. JavaScript, CLR, JVM and LLVM backends are under development by third-parties.
I developed the LLVM backend from 2013 through 2014. Unless there's a new repository or unrelated effort I'm unaware of, it has been unmaintained ever since. I moved on because I was sick of spending all my free time on a tooling project nobody else used, and because it was impossible to get edwinb to discuss making it officially supported, despite significant performance and portability benefits. I don't think he was interested, at least at the time, in having an officially supported backend that wasn't a stack machine (which is what the C code that the official backend emits behaves like). Never made a lot of sense to me; translating a lambda calculus to SSA form is very intuitive :shrug:

That said, dependent types are absolutely glorious and everyone should be very excited about them becoming more accessible. I'm optimistic that Haskell will eventually provide them in a non-awkward way (it's been going that direction for a while), but what I really dream of is Rust someday getting there. Writing arithmetic proofs can be annoying, but real-world code is full of issues arising from people getting simple arithmetic wrong, so it doesn't really seem gratuitous.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Shinku ABOOKEN posted:

Genuine question: What's the real world utility of dependent types?
Same as static types, but moreso. They enable the compiler to check for violations of more of your code's invariants. For simple code sometimes a compiler can even infer parts of your code for you!

e: Whoops, this has already been answered thoroughly. Oh well.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
Alternatively, Software Foundations is available for free in its entirety. It teaches dependent types using Coq, which has many of the fancy features Idris dreams of, up to and including a smart editor tightly integrated with the compiler. This is the language that CompCert, the proven-correct C compiler, is written in.

xtal posted:

Dependent types are p much the best CS invention in my short lifetime. They can theoretically eliminate runtime errors. Making your program total and terminating is sometimes an additional benefit.
Intuitionistic type theory was introduced in 1972. Sorry to say, you're old.

Ralith fucked around with this message at 06:22 on Dec 2, 2016

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

Does anyone know if Typed Racket or Clojure has support for quasi-dependent types? Gradual types seem like a nice compromise to me since you don't need to type absolutely​ everything​, and you can still statically verify them.
A year or so ago when I was working on some Typed Racket code (a rather nice experience, though compile times aren't great) I heard about an ongoing effort to add dependent types to it; I haven't kept up with it but it's a good direction to look.

rjmccall posted:

I did research on a "practical" dependently-typed language for a year in grad school, and yeah, this was my experience: you spend a lot of time proving basically trivial things. And that was for well-known problems like discussing the length of a list; my experience with trying to prove novel things about real programs (this time in Coq) was that even formulating the types in a way that allowed a proof to proceed was just an unending series of major research problems, which is not a surprise to anybody who's ever done real mathematics, but which constantly seems to surprise the CS folks.

My takeaway was that you should always strive to write code that you could make a rigorous argument about. Having done that, you should then go write good documentation about your preconditions and check them with assertions.
My experience with Idris was consistent with this, but I remain strongly of the opinion that it's good to have the ability to make strong, precise statements in your type system, even if actually doing so to the maximal extent is a gigantic can of worms. Nothing's forcing you to use every tool available to you at all times.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Gnumonic posted:

The anonymous function and squish2 each return a list, not the first item of a sub-list, and I can't understand why the "correct" version of squish doesn't do the same. (i.e. I can't figure out why the output isn't [[1,2,3],whatever] rather than [1,2,3,4,5]). Am I missing something really obvious?
The first item of a nonempty list-of-lists is a list.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

What is the best language to use on a Raspberry Pi? Haskell runs fine but lens has been compiling for over a day
If you can live without being MAXIMUM FUNCTIONAL, rust's nice, and has a pretty good embedded story.

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

Self-quoting for context. How much of a coding horror would it be for me to make a Lisp syntax for Rust using Haskell and parsec?
Pretty horrifying from a long-term maintenance perspective, but straightforward enough.

One of the fun things about the Rust compiler is that it's pretty well factored into a bunch of distinct libraries--you might actually be able to just drop in a new front-end rather than doing syntax-to-syntax transforms. You'd need to write a parser in Rust to do that, but s-expressions are pretty easy and nom may not be parsec but people seem to like it. This will probably be even less stable than something that emits rust syntax, since internal compiler APIs change whenever they like, but would IMO be a way more interesting project.

Asymmetrikon posted:

Well, I'm doing this for C (with intent to create a lot of macros to automatically do generics/monomorphisation/better types/etc.,) so I'd be a hypocrite if I didn't say go for it :getin:
Not to be an evangelist or anything, but FYI Rust is basically what you get if you start with C and add all those things. Maybe have a look!

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today
My two most recent Haskell projects were a geospatial webapp for a hackathon at work, and little GUI utility to implement the Schulze voting method (lesson learned: never, ever try to write a portable GUI by using GTK in any language).

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

Ploft-shell crab posted:

I'm looking at Idris.

Can anyone shed some light on what's going on here:
code:
data Fin : Nat -> Type where
   FZ : Fin (S k)
   FS : Fin k -> Fin (S k)
I think I understand what Fin 5 represents, but what's going on with these constructors??
Remember that k : Nat is implicitly universally quantified, because it's lower case. Read the constructors as "for all Nats k, FZ inhabits Fin (S k)" and "for all Nats k, applying FS to a Fin k produces a Fin (S k)"

Adbot
ADBOT LOVES YOU

Ralith
Jan 12, 2011

I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

xtal posted:

Any of you guys hosed with Idris? 1.0 just came out and I want to use it but there's still no package manager...
I used to contribute to Idris. These days I use (and occasionally contribute to) Rust instead, because it is actually intended to be a useful language for building things, and that's what I'm interested in doing. Still really excited about dependent types, but I guess it's not their time yet.

xtal posted:

Having Idris use a general package manager would be way better than building another package manager for every single language but Nix looks kind of hacky and cruddy tbh
Nix is the best thing since sliced bread. 17.03 just got released, including my work to get Vulkan working! Gotta say I'm a big fan of how open the Vulkan-related Khronos processes are to community involvement; upstreaming the relevant patches was very smooth.

  • Locked thread