From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8C9FDBBAF for ; Sun, 8 Aug 2010 20:44:12 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMCAM+XXkzRVdY0kGdsb2JhbACBRJ54CBUBAQEBCQkMBxEDH6ZgiRCCEYUTLohUAQEDBYU1BIk7 X-IronPort-AV: E=Sophos;i="4.55,338,1278280800"; d="scan'208";a="67401289" Received: from mail-bw0-f52.google.com ([209.85.214.52]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Aug 2010 20:44:12 +0200 Received: by bwz17 with SMTP id 17so1032932bwz.39 for ; Sun, 08 Aug 2010 11:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5MmqYs2dDm0GaQgVbFpD/YJePKd27/uaz3QRw4vlCIk=; b=PLEPEfDDMrI1k++cg+huZntM3VQm0ASvsND93Qmx8J9iwleYauRyUZV0lvDUiHg1/P JVvN+3pTlGSMQYGbPU1dROh09AuATJvTer48O96BA8fLbwPXN+FcuHRuixcXkcxOeZ5L Vm1SHTeGDDRTR7hF030B/vANxO2SX4x74+5hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pbGwUjKg+BJmLLvbUcOlGK6dr2+dp8yfgPfzaX8nGtSKigFwdGxdeTM7XZDGycXbdJ srmKXuwd3i7R+FxouRJaFOs/XsEpO8gzgCiWomCWiCRaA0sOdZ+OX1q59sPhGT9kFoB4 2BctJa8YKvYpdvDRnttlopbLpTu3vdRlztYk8= MIME-Version: 1.0 Received: by 10.204.19.83 with SMTP id z19mr2227370bka.43.1281293051483; Sun, 08 Aug 2010 11:44:11 -0700 (PDT) Received: by 10.204.54.68 with HTTP; Sun, 8 Aug 2010 11:44:11 -0700 (PDT) In-Reply-To: <877hk1m1df.fsf@mid.deneb.enyo.de> References: <877hk1m1df.fsf@mid.deneb.enyo.de> Date: Sun, 8 Aug 2010 14:44:11 -0400 Message-ID: Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml? From: Jeremy Bem To: Florian Weimer Cc: caml-list List Content-Type: multipart/alternative; boundary=00032555a3da2fd677048d5449e3 X-Spam: no; 0.00; ocaml:01 typechecker:01 mutable:01 type-safe:01 ocaml:01 typechecker:01 mutable:01 type-safe:01 owing:98 owing:98 equality:01 equality:01 polymorphic:01 polymorphic:01 wrote:01 --00032555a3da2fd677048d5449e3 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 8, 2010 at 1:59 PM, Florian Weimer wrote: > * Jeremy Bem: > > > To support my research, I've developed an implementation ("Llama Light") > of > > the core Caml language. Modules, objects, labels etc are not supported > > (except for file-level modules). The system strongly resembles OCaml, > > however the completely rewritten typechecker is not only much smaller in > > terms of lines-of-code; it has a genuinely simpler design owing > especially > > to the lack of first-class modules. > > How do you deal with strings (are they mutable?) and polymorphic > equality (is it type-safe?)? > Yes and no, respectively. In other words, nothing new here. Strings can be made immutable (in both Llama and OCaml) by disabling String.set in the standard library (the s.[i] <- c construct is just sugar for a call to that function). Is there a better approach to polymorphic equality floating around? -Jeremy --00032555a3da2fd677048d5449e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Aug 8, 2010 at 1:59 PM, Florian = Weimer <fw@deneb.e= nyo.de> wrote:
* Jeremy Bem:

> To support my research, I've developed an implementation ("Ll= ama Light") of
> the core Caml language. Modules, objects, labels etc are not supported=
> (except for file-level modules). The system strongly resembles OCaml,<= br> > however the completely rewritten typechecker is not only much smaller = in
> terms of lines-of-code; it has a genuinely simpler design owing especi= ally
> to the lack of first-class modules.

How do you deal with strings (are they mutable?) and polymorphic
equality (is it type-safe?)?

Yes and no= , respectively. =A0In other words, nothing new here.

Strings can be made immutable (in both Llama and OCaml) by=A0disabling String.set in the standard libr= ary (the s.[i] <- c construct is just sugar for a call to that function)= .

Is there a bett= er approach to polymorphic equality floating around?

-Jeremy
--00032555a3da2fd677048d5449e3--