Re: pattern matching

"Douglas Lewit [email protected] [ocaml_beginners]" <[email protected]> Tue, 29 Mar 2016 19:28:26 -0500
Newsgroups gmane.comp.lang.ocaml.beginners
Message-ID <CAM0XMJQahO1DqdiqGWvNrwyzoifPxu=7yYcN3_mkE4rJdZGV3g@mail.gmail.com>
Hi Ken.  Now I'm really curious.  Can you tell me more about Merlin and....
this other tool that is integrated into Emacs?  ( I can't seem to find that
message, but you mentioned Merlin and some Emacs extension I believe....
Ocaml-Potter or something like that? )  I've messed around with Emacs.
Definitely very nice editor.  I like how it saves a copy of your previous
file.  So if I edit Practice.java in Emacs, I end up with Practice.java and
Practice.java~ in the same directory.  That's a really good deal because
it's possible that I screwed up Practice.java very badly in which case I
would just use the Terminal command:

mv Practice.java~ Practice.java

and then I'm right back where I started before all my bad editing.

But I must confess that I don't really use Emacs that much anymore.  I've
become more of a Vim guy.  The reason is simple.  I've noticed that Vim has
way more online resources and online support than Emacs.  There is online
help for Emacs too, but.... it just seems like I need a PhD. in CS or
Physics from MIT in order to utilize those resources.  The Vim tutorials
are a little more "down to earth" for the "average" programmer.  ( I kind
of hate that word "average", but you know what I mean. )  I've also found
that when I write a file in Vim, it looks really weird when I open it up in
Emacs.  All the tabs and indentations are way too big!  I think in my
.vimrc file I specified a tab of 4 spaces, but when I open the file in
Emacs I end up with one tab being equal to like 8 spaces or something like
that.  Very annoying.

I do like utop a lot for Ocaml.  Very nice.

I've also recently discovered Ocaml's Sys module, with builtin commands for
file management, system administration, etc.  Very helpful stuff.  Although
I'm going to be the Devil's Advocate here and ask why we can't just use
Bash to do the same thing?

Have a great week.

Best,

Doug.



On Tue, Mar 29, 2016 at 11:00 AM, Kenneth Miller [email protected]
[ocaml_beginners] <[email protected]> wrote:

>
>
> I didn't mean to confuse you Doug, I'll explain each in turn.
>
> You can call C functions with ocaml-ctypes, which is actually a wrapper
> library to some inherent inbuilt functionality that derives all the way
> from some language primitives ("external" keyword). It just makes it easier
> for you.
>
> YNot is a paper about a Coq module that facilitates reasoning with Hoare
> Type Theory. I thought was really excellent by Harvard's Greg Morrisett. It
> strives to capture co-program-proof construction spirit in Coq, which so
> far has a superb kernel and fantastic CIC foundation, but that has been
> lacking monad style hoare reasoning for a while. He integrated the
> reasoning basis into the type system so that you can write things like ring
> buffers and hash tables and reason about their correctness while still
> allowing side effects.
>
> Basically, no one wants to pay the cost of re-implementing software, and
> for good reason. Software is difficult to maintain and very expensive. So
> people take shortcuts in all languages.
>
> In my opinion, the foundational definitions of types and their default
> behavior are critical because you want to express to the user in each class
> of situations what has happened. In the case of having behavior default to
> nil or to some other type instance, you haven't actually expressed back to
> the user what should be done; the designers just assume 0 or nil will be
> good for you. You then end up doing the extra work to learn the individual
> behaviors of various functions in order that you not step on a land mine.
> That's much more expensive than getting a type error where the compiler
> tells you the cases that you haven't considered. (And which you can
> introspect with merlin!)
>
>
> On Tuesday, March 29, 2016 11:42 AM, "Douglas Lewit [email protected]
> [ocaml_beginners]" <[email protected]> wrote:
>
>
>
> Hi Ken,
>
> What do you mean that "every language has an escape hatch to C"?  I'm not
> familiar with YNot.  Judging by the context, I would assume that YNot is
> some Ocaml module that allows Ocaml to directly implement C code.  I know
> they do this occasionally in Python and Ruby for the sake of speed, but why
> is this necessary in a language like Ocaml?  I thought Ocaml was just as
> fast as anything written in C?
>
> Ruby is a nice language, but at times it appears to be a little too
> forgiving.  ( But please bear in mind that I am NOT a Ruby pro or expert,
> so this is an amateur's opinion. )  So for example in most languages if you
> have an array or list like this:
>
> myList = [1, 2, 3, 4, 5] or [1; 2; 3; 4; 5] or you get the idea, and let's
> say I do this: myList[10] or ( List.nth myList 10 ) or something to that
> effect, I will get back an error!  Ruby has no
> ArrayIndexOutOfBoundsException.  If I do that in Ruby, I'll just get nil.
>  ( Ruby's version of null. )  I know from experience that C++, Java,
> Python, and Ocaml will return an error message.  But Ruby permits this and
> just returns nil.  If the user is prompted for integer input in Ruby, and
> the user enters "Hello World" ( which certainly is not an integer! ) then
> the string gets converted into the integer 0 if you call the *to_i*
> method.  I found this to be rather annoying when I wrote this program where
> I wanted to validate the user's input for correctness.  "Hello World" is
> not valid input!  But Ruby just passed the string along into my integer
> array, but the string got converted into 0, which is the default integer
> value in Ruby.  So Ruby is very, very forgiving.  That's great if you're
> new to programming.  But that forgiving nature can lead to some issues if
> you want to validate user input, etc.  But again.... I'm no Ruby pro!  I'm
> sure that a professional Rubyist would have some way to address this
> particular issue.
>
>
>
> On Tue, Mar 29, 2016 at 10:11 AM, Kenneth Miller
> [email protected] [ocaml_beginners] <
> [email protected]> wrote:
>
>
> Patterns are expressions; you can write anything that fits the data type
> recursively, so long as you obey the type definition. To give you an idea,
> go back and look at Mr. Herr's definition; a head::second::tail is a list
> just as much as a [] is or a head::[], get it? Whatever it is that you
> pattern match, must deconstruct down to some legal construction component
> parts of a list in order that it can be said that the expression as a whole
> is a list.
>
>
> On Tuesday, March 29, 2016 11:06 AM, "Douglas Lewit [email protected]
> [ocaml_beginners]" <[email protected]> wrote:
>
>
>
> Some of it I got, and some I didn't.  But here's a question.  In pattern
> matching, can I simply write [head]?  Or am I obligated to write head :: [
> ].  They're interchangeable, right?  ( Although the syntax may require one
> rather than the other.  I would have to experiment with it to find out. )
>
> On Tue, Mar 29, 2016 at 4:02 AM, 'Mr. Herr' [email protected]
> [ocaml_beginners] <[email protected]> wrote:
>
>
> sorry, overlooked sub matching.
>
> You can match several elements in one pattern, just take care to have the
> "shorter" cases first.
>   | []  ->
>   | head :: [] -> (* equivalent to [head], all list patterns can be
> written with square brackets *)
>   | head :: second :: rest -> (* here rest can be [] *)
>
> This sounds like you did not understand the explanations I gave.
>
> /Str.
>
> On 29.03.2016 10:18, 'Mr. Herr' [email protected] [ocaml_beginners]
> wrote:
>
>
>
>
> On 29.03.2016 06:41, Douglas Lewit [email protected] [ocaml_beginners]
> wrote:
>
>
> I also gave something like this a try, but I ended up with a couple of
> error messages:
>
> *let pack list = match list with*
> *|[ ] -> [ ]*
> *|head :: tail -> match tail with*
> *|[ ] -> [ ]*
> *headOfTail :: tailOfTail -> if head = headOfTail then..... ( more code )*
>
> I thought it was clever, but either I just ended up with an empty list, a
> one-element list, or the compiler just rejected it.  I'm starting to feel a
> little dumb!  But I'll keep at it.
>
> tailOfTail is a list, not an element!
>
> /Str.
>
>
>
>
>
>
>
>
> 
>