lainchan / λ

(untitled)

Kay · 2018-04-15 07:39
I'm accustomed to algol descendents and have done some lisp but never any ml. What's the best in? OCaml? Is there much industry use?
Unsigned · 2018-04-15 12:07
>>7879 OCaml is quite developped as a language. It's about on par with Haskell, and I think might be more in use in the industry : - janestreet is a big user and contributor - facebook recently launched a spinoff of ocaml called reason. They only made some aesthetic changes for whatever bullsoykaf reason. There is notoriously a lack of libraries for some uses (web and stuff like that), but there are good build systems (I use oasis, I heard there is a another one gaining traction), package manager (opam). Overall I appreciate this language quite a lot, although the lack of libraries is sometimes bothersome.
Dr. X · 2018-04-15 18:42
OCaml is definitely the best right now among the direct ML descendants. SML has some really good optimizing compilers (MLton is one of the best compilers there is in general, and CakeML is fully formally verified), but its ecosystem is sorely lacking; libraries are very sparse and there's not much of a community. Almost all SML code is written by academics for their compilers, so it'll most likely be very ugly, monolithic, and undocumented. As for the language itself, it's much like OCaml but it feels very basic. I also personally find it ugly compared to OCaml. Here's a page comparing the two languages: http://adam.chlipala.net/mlcomp/ OCaml only has one (usable) implementation, but it's really high quality and convenient features are being worked on and added with every release. It's gained a lot of traction in the last few years thanks to Jane Street's effort into making the ecosystem grow, and it's probably gonna become more popular with Facebook pushing ReasonML (which is just a different syntax for OCaml). Libraries are comparatively few but they're usually pretty high quality, and there's people putting a lot of effort into making the ecosystem better. If you want to learn an ML derivative I definitely recomment OCaml, though I doubt you're gonna find a job using it. I can't speak much for F# because I've never used it, but it's pretty similar to OCaml with a slightly different set of features (no functors, units of measure, overloading, object system that's integrated with C#'s).
quote · 2018-04-15 22:55
I personally think SML is better than Ocaml, there are better books out for SML (see last few posts of book thread) and a lot of good implementations to choose from (I use PolyML). The syntax of SML is just clearer and easier to use IMO. this free book is considered to be the best ML book, if you read it you will understand all of ML: http://www.cs.cmu.edu/~rwh/isml/book.pdf
Hong, Guil Dong · 2018-04-16 01:55
What about F#?
Roger Pollack · 2018-04-16 09:13
>>7889 >there are better books out for SML Pretty much all SML books are applicable to OCaml too; there's very little you can do it SML that you can't in OCaml.
Wintermute · 2018-04-16 19:48
>>7891 the advantage of F# is being able to use all the .NET and windows system libraries, lack of libraries are the only disadvantage of SML/Ocaml
Jens Hansen · 2018-04-17 13:36
Pardon my ignorance, and a bit of thread highjacking. The other day I was debating whether I should learn Ocaml or Scala first. I went with Scala, as there seems to be a push in some areas of my firm to use it. During my investigations on the topic, I read someone say that Scala is Ocaml for the JVM. How are Scala and ML related, other than good support for pattern matching, object orientation and functional programming?
null · 2018-04-17 20:19
>>7914 Scala is an experiment to combine OO with FP, the only people who seem to use it are people who already use Java and want FP. Ocaml is a functional language with OO features added (the O in Ocaml stands for object orientation). So if youre heavily invested in the JVM ecosystem it might be worth looking into as well as other JVM languages like Kotlin, Clojure, Groovy, etc.
藤原純一 · 2018-04-18 04:38
I'm thinking of getting into compilers and heard that the Appel book is very good. It uses SML. I have some previous experience with Haskell, is SML easy enough to pick up that I'll just be able to dive in after a few hours reading up on the differences? Or should I expect a somewhat more significant period of study? Also, SML seems to have almost as many implementations as Scheme, is there a guide as to which implementation to pick? (Though to be honest I might be better served by just starting to read the book and get started on some examples than by asking here.)
Sabo Engle · 2018-04-18 07:01
>>7922 Actually, would following the Tiger book in OCaml be viable? Does it use SML-specific features?
Turing · 2018-04-18 07:15
>>7920 So, let me check if I understand what you mean. In scala object orientation is one of the main goals of the language, while in Ocaml, object orientation is an addition, let say optional. Is that right? You don't seem to like scala very much, care to elaborate? I am about finished with the first of Odersky's courses on coursera. So far, it looks like a nice language. Granted, I am more accustomed to non object oriented FP languages (Clojure and R), and the whole OO is completely alien to me. But I feel like scala is finally allowing me to GET object orientation.
Stallman · 2018-04-18 07:59
>>7924 The "SML-specific" features you talk about amount to some advanced usage of functors involving type sharing between opaque types in different modules. You're unlikely to ever run into problems with that unless you read a book specifically about advanced SML features. So yes, it's completely viable to follow the tiger book with OCaml, you'll just have to learn the syntax of ocamllex and ocamlyacc for yourself, which is a bit different from their SML counterparts.
Torvalds · 2018-04-18 08:24
>>7926 There's also call/cc in SMLNJ. Though I'd be surprised to see it come up. I hate call/cc, so I don't mind not having it.
Sabo Engle · 2018-04-18 09:03
>>7925 >So, let me check if I understand what you mean. In scala object orientation is one of the main goals of the language, while in Ocaml, object orientation is an addition, let say optional. Is that right? The goal of Scala is to be functional AND object oriented, which I think is sort of weird. Its hard enough to program in languages that are just functional, but Scala is just like an OO flavored functional language. For example I like a language like Elixir which takes pure functional programming and gives it more of an imperative feel. I like how Rust is an imperative language and gives it a lot of functional features so that it can be immutable when you want. I like Smalltalk which I believe is pure OO with emphasis on message passing which makes it more functional. But Scala sort of tries to be pure functional AND pure OO which is just weird. >You don't seem to like scala very much, care to elaborate? I dont dislike Scala, if I were a Java programmer I would give it a serious look as I believe that Scala could make someone more productive than just using Java. For example this talk was given a long time ago and I think well illustrates the advantages that Scala gives over Java: https://www.youtube.com/watch?v=LH75sJAR0hc
John Rain · 2018-04-19 19:30
Is there a cheat sheet somewhere for translating between SML and OCaml?
Jens Hansen · 2018-05-04 09:27
>>7930 I have to agree that scala is pretty weird. But I am enjoying the mixture so far, as scala is allowinging me grasp the whole object orientation. Given that ML also has object orientation, I guess this is a good place to ask. Where do you see the benefits of object orientation over the just functional approach? I do not do very complex programs for the most part, just small or medium sized scripts, and they endup being a whole lot of functions, and a couple of calls to those functions. I do not see how can object orientation be useful to me. Are the benefits noticeable as projects grow larger?
Guthrie · 2019-03-19 06:21
>>7955 I'm pretty late to the party, but I discovered now this ML world. Here is a syntax comparison that you can use to translate: https://people.mpi-sws.org/~rossberg/sml-vs-ocaml.html
Elliot Alderson · 2019-03-20 16:27
>>8179 In OCaml the O isn't used as it's not practically useful, as you have a module system with functors. The module system is simply more expressive and one should only use an object system in the following 2 cases: 1. You need late binding. Modules are early binding 2. You want inheritance. - inheritance is a very dangerous tool (it's very brittle), and you could get better millage by leveraging the functor system
pop · 2019-03-21 05:30
>>7889 >the best ML book ML For The Working Programmer is available for free on the authors website. https://www.cl.cam.ac.uk/~lp15/MLbook/
string · 2019-03-22 15:40
Sorry if this belongs in the Beginners General, or even the Book Thread. A friend and I are interested in learning OCaml (reasoning here: >>12761), so we're looking for book suggestions. I think I'd consider myself a intermediate programmer, I've worked through SICP, a college C++ class and written a (still buggy) radix-tree library in Scheme along with some small applications for my daily use in C. My friend is less experienced but has some knowledge of shell scripts, a dialect of C for robotics, and a small amount of R. I found the following book: http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/ which seemed good but I'd like a third party's opinion on how it would match up to our divergent skill sets. Also I've noticed it seems a little lacking in exercises. If we went this route would supplementing it with http://ocaml.github.io/ocamlunix be a good idea or would something more benign like Project Euler be better? I know you can't fully understand our skill levels entirely from this post, but any suggestions would be very appreciated, thanks in advance.
Bobby Newmark · 2019-03-24 16:22
>>12938 Sorry if anyone was working on a respond to this but hasn't posted yet. It seems likely that my friend and I are going to work through: http://dev.realworldocaml.org due to its frequent suggestion elsewhere.
quote · 2019-03-26 19:14
>>12968 RWO is a fun book to read through. It reads nicely. I find core to be a very good standard library. Sadly it just lacks documentation. One of my favorite modules it adds is the Stream module
Meddler · 2019-03-27 13:58
>>13015 >RWO is a fun book to read through. It reads nicely. That's good to hear! I read most of section 1 yesterday and I agree so far. >I find core to be a very good standard library. Sadly it just lacks >documentation. One of my favorite modules it adds is the Stream module Yah, in the prelude it says it's not intended as a reference manual, so maybe I'll read through the standard and the Core documentation when I'm done. In the Scheme implementation I used streams were the only efficient means of constructing strings at runtime, so I ended up using them a good bit. I look forward to seeing how OCaml does this.
cdr · 2019-04-04 00:41
>>13019 >Sadly it just lacks documentation. >Maybe I'll read through the standard and the Core documentation when I'm done. Not sure what happened here, sorry about that. I'm now on section 5, Records. I'll be honest I'm not actually the biggest fan of this book so far. It seems to straddle a awkward middle ground between a reference text and a introductory text doing neither particularly well. It doesn't offer any practice problems only examples and fails to cover most libraries and concept fully. It also does a poor job of isolating concepts frequently mixing many different parts of libraries and concepts in each section. I do really enjoy the language so far though, I can already start to see how great pattern matching and powerful types are. I'm looking forward to actually writing something in it. (something to liven up this thread a bit!)
Anonymous · 2019-04-04 05:02
>>13101 Hmm that's a shame, I don't really know any other OCaml books. It might have read fine for me since I came from a Haskell background, so to me it quickly got me up to speed about what OCamler's care about. If you want to checkout a big OCaml code base, I'd look at Tezos https://gitlab.com/tezos/tezos/ It does not use core, but it's a pretty big code base. Only things I've done wtih the language so far is do Advent of Code and De Bruijin indincies. Will be doing much more in a few months
Turing · 2019-04-05 03:06
>>13108 >Hmm that's a shame, I don't really know any other OCaml books. It might have >read fine for me since I came from a Haskell background, so to me it quickly >got me up to speed about what OCamler's care about. I probably made it sound worse than it seems, my friend and I certainly intend on completing it. I could see it being great in your situation. >If you want to checkout a big OCaml code base, I'd look at Tezos I downloaded the repo, I'll definitely look through it. >Only things I've done wtih the language so far is do Advent of Code and De >Bruijin indincies. Will be doing much more in a few months. Fun stuff! I've got no idea what I'll write yet, probably nothing too interesting; I'm not a skilled programmer and even less so in OCaml.
Sabo Engle · 2019-11-19 19:41
Hello, I'm currently programming a markup parser in OCaml using Angstrom and I've run into a bit of difficulty implementing some of the features I'd like. Namely I'd like to be able to pass a stack of all scoped formatting rules to each recursion of my parser so that I can allow for formatting elements to be closed in the scope of another nested formatting element (closing, and reopening those elements lower in the stack afterwards), and more easily allow for opening tags without a matching closing tag to simply be interpreted as a non-special string. The issue I've run into is that the built in fixed-point combinator for Angstrom is implemented using laziness, and is typed as val fix : ('a t -> 'a t) -> 'a t where t is the parser type. The laziness seemed to break the use of a mutable stack (it's possible I'm incorrect here), and the type seems to have made it where I can't simply add the stack to my parser naively. Additionally due to the way Angstrom is written fixed-point combinators seem like they would need to rely on the internals of the library and would be subject to rot if I wrote it myself because of this. Would anyone happen to know of a way that I can pass around my stack without programming and maintaining my own fixed-point combinator for Angstrom?
overriding · 2019-11-20 23:43
Ocaml is a "pragmatic" piece of crap. Use SML. MLton, moscow ML, sml/nj, i dunno
Demeere · 2019-11-21 01:46
>>15949 I updated Angstrom this morning and tried again, I have to use mutation, but I was able to start achieving my objectives. I don't see any mention of the issues I was having with mutation in the change logs so it must have been some other change I made to the parser since yesterday which resolved it. I'm not sure what, sorry for bothering you.
BloodCat · 2019-11-21 03:32
>>15961 Actually I was wrong, it's still broken. The issue I'm having is that my mutation seems to be performed when the parser is defined rather than when it is evaluated, and there seems to be another error of some sort with my removing of the a element from the scope. Following is a toy example of the type of parser that results in these errors: let dispatch = let scope = ref [] in fix (fun parser -> let bold = string "**" *> begin scope := Bold_Text :: !scope; many parser end <* begin scope := List.tl !scope; string "**" end >>| fun x -> Bold x in ...)
Nobody important · 2019-11-21 17:59
>>15969 The reason for this, is due to semantics When you say `let foo = 5` That happens right away, why wouldn't the mutation also happen right away? A way OCamler's fix this is by the following ```ocaml let dispatch () = ``` Though since you are using angstrom, why use mutation like this? why not instead parse into making some ADT structure or a list of ADT structures?
Unknown · 2019-11-21 19:22
>>15972 I guess I should have thought to just use a thunk cheers! >Though since you are using angstrom, why use mutation like this? why not instead parse into making some ADT structure or a list of ADT structures? I am parsing to a ADT, my reasoning for using mutation may be incorrect but what I said in >>15949 was "I'd like to be able to pass a stack of all scoped formatting rules to each recursion of my parser so that I can allow for formatting elements to be closed in the scope of another nested formatting element (closing, and reopening those elements lower in the stack afterwards), and more easily allow for opening tags without a matching closing tag to simply be interpreted as a non-special string." I've implemented a working version of my parser already which handles everything but theses sort of malformed cases and a parser for links but no dispatch for it. Here's my ADT if you're curious: type code = | Inline of string (* ```fun x -> x``` *) | Block of string (* Inline_Code but with internal newline(s) *) type ref = | Board of string list | Thread of string option * int list | Post of string option * int option * int list type t = | Code of code | Reference of ref | Quote of t list (* \r\n>Quote *) | Bold of t list (* **Bold** *) | Italic of t list (* ~~Italics~~ *) | Spoiler of t list (* /*Spoiler*/ *) | Paragraph of t list (* \r\n Paragraph \r\n\r\n... *) | Link of string (* https://example.com *) | Text of string (* any string not otherwise parsed *) | Newline (* \n or \r\n *)
Spooky · 2019-11-21 22:45
There was another issue in that because OCaml is strictly evaluated both the begin ... end blocks were being evaluated before being fed into the combinators. The solution to get around this is rather ugly, but it works. Thanks for your help anon. let ( >>! ) x y = x >>| fun z -> (y); z let bold () = (string "**" >>! (fun () -> scope := `Bold :: !scope)) *> (many text >>! (fun () -> scope := List.tl !scope)) <* string "**" >>| fun x -> Bold x
Davis · 2019-11-28 14:30
>>15975 >>15973 It seems you are parsing things by Paragraph? Hmm, it seems you are conflating priorities with the parser this way? The parser should just handle forms as they come, so when you see a bold, do something like <code> let bold = sep_by (string "**") text >>| fun x -> Bold x <\code> This allows your parser to be flexable and not really care what comes before it. In processing then you could recurisvely pass things. Another issue with your technique is that I could write ** wrds here And never close off the **
Von Neumann · 2019-11-28 18:46
>>16048 >It seems you are parsing things by Paragraph? I'll attach the full parser I've implemented, although it is seeming as if I have to abandon the implementation I currently have and migrate over to sedlex and menhir so that I can have unicode and actually implement the features described. It has a lot of excess broken code in it currently from when I was trying to make these features work. >Hmm, it seems you are conflating priorities with the parser this way? The parser should just handle forms as they come, so when you see a bold, do something like I'm not sure I understand what you mean, are you saying that these features are unreasonable? I already implemented a parser which handles a "properly formed" (where every formatting element is closed at the same level it was opened) version of my markup which is implemented similarly to the way you've described, although it renders a opening tag such as "**" without a matching closing tag simply as its self in plaintext as this is my preference.
St. IGNUcius · 2019-12-01 06:08
>>16048 I've decided to actually follow your advice for the moment, although I'm not very happy about it. I consider this a 80% solution, and it disappoints me that this epidemic of modern programming is something I'll be contributing to. I'll be creating a detailed note file of the features I'd like to implement but don't have the time to implement currently, with the intent of circling back and rewriting things. This is just part of a individual module, and the API will not need to be modified with these changes so it shouldn't be any harder to correct later on than it would be currently.
Davis · 2019-12-25 20:14
D: Help :'( Function is not exhaustive. missing pattern: (_, _, _, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, :: _))))))))) | (_, _, _, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, nil)))))))) | (_, _, _, :: (_, :: (_, :: (_, :: (_, :: (_, :: (_, nil))))))) | (_, _, _, :: (_, :: (_, :: (_, :: (_, :: (_, nil)))))) | (_, _, _, :: (_, :: (_, :: (_, :: (_, nil))))) | (_, _, _, :: (_, :: (_, :: (_, nil)))) | (_, _, _, :: (_, :: (_, nil))) | (_, _, _, :: (_, nil)) | (_, _, _, nil)
Anonymous · 2019-12-25 22:14
>>16308 It seems you've written a non exhaustive function. You seem to have a list of tuples that you are matching deeply on. Probably best to make a struct or something if you want something that deep, since you are going out to such a degree
byte · 2019-12-26 18:10
>>16309 I'm not the same guy, I just thought the was the ML thread.
quote · 2019-12-31 22:50
Hey folks, I'm trying to understand cardinality of types, and I'm struggling a little to understand how cardinalities of zero affect the cardinality of functions. Consider the following example: type void let genesis : void -> bool = fun v -> false In this case our type theory would tell us that |a -> b| = |b|^|a| so |genesis| = |2|^|0| = 1. This doesn't make sense to me, how can void -> bool have any valid inhabitants if the argument doesn't have any valid inhabitants? If we flip the input and output of genesis we get a reasonable answer |genesis'| = |0|^|2| = 0 (however, this function can't be written in OCaml). Another thing I find confusing is that types with equal cardinality should be isomorphic to one another, but I can't make a function to map from a product type with void in it to void or vis versa. How should I go about reasoning about types of zero cardinality?
(λ x (David x (Gabriel))) · 2020-02-07 07:18
news.ycombinator.com/item?id=22246334 Hackernews say nice things about SML, and some comment talk about OCaml
Jim Hilger · 2020-02-09 06:00
>>16394 If you think about it from a set-theoretic perspective, how many functions are there from {} to {T,F}? A function F with domain C and codomain D is a subset of CxD (Cartesian product of C and D) with extra conditions. There is only one function between {} and {T,F}, and it is {}. What does this mean in the O'Caml perspective? Because you can't construct a value of type void and O'Caml is strict, all functions from void to bool are indistinguishable from each other. They are all the empty function, and error if you try to call them. That's the best I've got.
Crazy Jake · 2020-08-30 16:01
Multicore ocaml is coming, and is bringing some fun tools like algebraic effects https://github.com/ocamllabs/ocaml-effects-tutorial Would be fun to play with and construct an erlang like system once it comes out
Unidentified · 2020-09-21 14:16
>>20540 I've seen this, looks really cool and a bit overdue to be honest. It won't be merged soon as far as I know, they're putting parallelism (Domains) first if I read correctly.