caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Geoff Wozniak <geoff@wozniak.ca>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: some comments on ocaml{lex,yacc} from a novice's POV
Date: Wed, 06 Apr 2005 00:52:58 -0400	[thread overview]
Message-ID: <87vf70tsk5.fsf@nagash.wacky> (raw)
In-Reply-To: <200504051449.39133.jon@ffconsultancy.com>

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

Jon Harrop <jon@ffconsultancy.com> writes:

> Note that, in this case, I was referring to the detection of grammar
> conflicts and not static type checking.
>

Sorry -- that notion didn't come across very well in your message.  The
criticism was misplaced.  (And I hope that my response didn't come off as
an "ad hominem" fallacy.)

> Can you give an example where dynamic typing has helped you to prototype a 
> program more quickly than you could have done with static type checking?
>

It happens quite often when I write code for a specification that is
incomplete and I have to go back and change something.  For example, I was
recently working on a recursive decent parser for some grammar.  I was
interested to see what sentences in the grammar would look like, how they
would parse, and other things of this nature.  Basically, I was coding to
flush out the inadequacies of the design.

I was doing this in OCaml, but I found that I had to constantly create new
types to represent the different forms that could be found in the parse
tree.  Often, it would involve moving some element from one type to
another.  This resulted in me making minor changes to a few different
functions in order for the program to type check.  It would have been
considerably simpler to just throw the element into a cons cell with the
first element being a symbol/string/whatever that just described the
element.  Then I would just write code that checked if the car/head of the
cons cell was X and if so, do something with it.

I am not advocating that this code would be suitable for release.  In fact,
I would have little faith in it and would probably be embarassed to release
it.  However, incrementally developing some program that does not have much
of a specification seems to be much simpler if I don't burden myself with
the act of conjuring up types for everything.  Once I've gone through a
couple iterations of the program, then I'm very interested in some form of
strong type checking to make sure that I'm not missing the little things.

-- 
Geoff Wozniak

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

  parent reply	other threads:[~2005-04-06  4:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-01 11:32 bug in "developing applications with objective caml" (english translation) Jack Andrews
2005-04-01 20:03 ` [Caml-list] " Ken Rose
2005-04-02  5:10   ` some comments on ocaml{lex,yacc} from a novice's POV Jack Andrews
2005-04-02  7:02     ` [Caml-list] " Erik de Castro Lopo
2005-04-02  7:38     ` Jacques Garrigue
2005-04-03 16:18       ` Parser combinators [was: some comments on ocaml{lex,yacc} from a novice's POV] Alex Baretta
2005-04-04  0:40         ` [Caml-list] Parser combinators Jacques Garrigue
2005-04-05 16:06       ` [Caml-list] some comments on ocaml{lex,yacc} from a novice's POV Oliver Bandel
     [not found]   ` <50130.202.164.198.46.1112418605.squirrel@www.ivorykite.com>
2005-04-04  3:42     ` Jack Andrews
2005-04-04  5:44       ` [Caml-list] " Erik de Castro Lopo
2005-04-04  9:51         ` Jon Harrop
2005-04-05 12:00           ` Geoff Wozniak
2005-04-05 13:49             ` Jon Harrop
2005-04-05 14:26               ` Richard Jones
2005-04-05 16:13                 ` Oliver Bandel
2005-04-06  4:52               ` Geoff Wozniak [this message]
2005-04-06  5:12                 ` Kenneth Knowles
2005-04-06  6:15                 ` some comments on ocaml{lex,yacc} from anovice's POV Jack Andrews
2005-04-04 10:29         ` [Caml-list] Re: some comments on ocaml{lex,yacc} from a novice's POV Daan Leijen
2005-04-04 17:39         ` Paul Snively
2005-04-04 18:16           ` skaller
2005-04-04 18:49             ` Paul Snively

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vf70tsk5.fsf@nagash.wacky \
    --to=geoff@wozniak.ca \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).