caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Rogoff <bpr@best.com>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] function vs. parser
Date: Thu, 13 Sep 2001 13:55:48 -0700 (PDT)	[thread overview]
Message-ID: <20010913134256.K27066-100000@shell5.ba.best.com> (raw)
In-Reply-To: <B1E4D3274D57D411BE8400D0B783FF322E86FF@exchange1.cswv.com>

On Thu, 13 Sep 2001, Krishnaswami, Neel wrote:

> Brian Rogoff [mailto:bpr@best.com] wrote:
> > On Thu, 13 Sep 2001, Daniel de Rauglaudre wrote:
> > >
> > > Same problem with "type": in my parsers, I would like to
> > > have "expr", "patt" and "type". I named it "ctyp", ugly too.
> > > And "constraint"... which is named "constrain" in the OCaml parser.
> > > It has been the problem with keywords since the Pascal language...
> >
> > It's funny that you should say that since the modern functional
> > languages play more tricks with lexical syntax than more mainstream
> > languages in order to carve up the limited namespace. We already use
> > capitalization and also funny 'identifiers for type variables. In Dylan
> > they rely on a bracketing convention for <types> to prevent clashes,
> > but I think it's only a convention.
>
> Yeah, it's a convention, since types are first-class values in Dylan.
> Such conventions are easy to create in Dylan because it's way permissive
> about which characters are legal in identifiers than most languages
> are -- almost all punctuation is legal. This produces a different set
> of complaints, though: people are unhappy that they have to write
> "foo + bar", because "foo+bar" is a distinct identifier.

This is a good thing IMO. The only exceptions of course being things like
(), ;, and ",".
>
> > In MLs, people generally don't seem to like such conventions (I've
> > gotten disgusted looks when I use the C convention of suffixing  _t
> > to type names in order to create a unique namespace for types :-) but
> > the ugliness pops up somewhere else.
>
> Doesn't Caml use such a convention to set the precedence of infix
> functions, so that *.. has higher precedence that +..?

Yes, be careful with | vs || and stuff like that with infixes. I got
burned there recently. Doh!

> I think that's
> pretty neat actually. I find it much more readable than Haskell's
> `backquote` mechanism.

But you can use names with backquotes.

> > Maybe in a post-Unicode world everything will be OK.

I guess I really should have put a :-) there, huh?

> Yeah, right. Combining characters and different code values with
> identical glyphs and the like make certain that the only result of
> Unicode adoption will be to increase the amount of confusion. I wonder
> if there's a computer equivalent to the second law of thermodynamics:
> the incoherence of a computer system always increases, or something
> like that. :)

I heard Robert Dewar describe it as the ratchet effect of programming
language design. Nothing ever gets removed, just added.

Oh well, as our erstwhile moderator said, CamlP4 rocks for the syntax
whiner. Maybe we should have another mailing list, the
caml-syntax-whining-list, for people like me who like to complain about
syntax? :-)

-- Brian


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr


  reply	other threads:[~2001-09-13 20:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-13 18:09 Krishnaswami, Neel
2001-09-13 20:55 ` Brian Rogoff [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-09-13 21:49 Krishnaswami, Neel
2001-09-14 12:50 ` Gerd Stolpmann
2001-09-13  8:20 SooHyoung Oh
2001-09-13  8:48 ` Daniel de Rauglaudre
2001-09-13 14:13   ` Brian Rogoff
2001-09-13 16:09     ` Daniel de Rauglaudre
2001-09-13 16:50       ` Brian Rogoff
2001-09-13 16:51       ` Pierre Weis

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=20010913134256.K27066-100000@shell5.ba.best.com \
    --to=bpr@best.com \
    --cc=caml-list@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).