From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 2EMOITadI2ZoNwEAqHPOHw:P1 (envelope-from ) for ; Sat, 20 Apr 2024 12:47:18 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2EMOITadI2ZoNwEAqHPOHw (envelope-from ) for ; Sat, 20 Apr 2024 12:47:18 +0200 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=Nh0JuPQb; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=cvf0gB9C; dmarc=pass (policy=quarantine) header.from=johnnyrichard.com; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1713610038; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-unsubscribe:list-subscribe: list-post:dkim-signature; bh=neijiQqefHOFeBsaejTXgutlWH7mXrbW8lc6WJjzo8Q=; b=QzrMiUslMkDQCTQb08Kqq5eL4E2eneF2Escm7iLakEn6J728QXv6HvKocO06ju7JbijzEm PY2CVRpH4ls1JW0CzAuIPdpDLm+k7xsJ0FeGgtllGB5mtKuQkwJpRwf2Lu99/tZKk4PKK9 Pxsz3EeJypSWuu77V8FKWVgdZA1Op7et8jMP95BvupStamNCD0oJCXnl03s5jICzgVIjul 8qDu/rHmUQ/gTRIhIr57I1Y2YDW5fWjPMzCKrfBWFErhlTJ2CmfaLilp8hLsIqizikmMgW DuRUL4qXBs1Wwx2Fp77aG9QbWvAglRRCJtJvV9m3N9PGbUVvKArIaEzQ5J7UkQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=Nh0JuPQb; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=cvf0gB9C; dmarc=pass (policy=quarantine) header.from=johnnyrichard.com; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht ARC-Seal: i=1; s=key1; d=johnnyrichard.com; t=1713610038; a=rsa-sha256; cv=none; b=U7mK512JOnjbeMjVC6XRe8670wK5jRRju7mqSx4wuH45006AHzNGkZYtWZqDNTjGMDIX/e tZ8qEoqSZGwGacirn/G9TbmHSRY8mObdINIHc9CjEqPjO5pRDOlSyQWGgDzlaixE8bUcdr T29I/L++DeiFjGtHpKqJPtmBLFFrwbF/fcNMdiSK7Sap2mItgQp06wxHvU7eD0gKyTrKMh JF7kSJHo+OdPWfqHuPUThN+IFHeqTDnzwMdfctbF2mdwA7Rv3VIPDiD5bXDBPZyh/IJUrO saZajhkG+mHM9FYuwqhS/1Dc5sf0MHJxqcSTmjIw5UsDOSGSPOQRmREK/PWq5A== Received: from mail-a.sr.ht (mail-a.sr.ht [46.23.81.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0457663E33 for ; Sat, 20 Apr 2024 12:47:14 +0200 (CEST) DKIM-Signature: a=rsa-sha256; bh=G/AOOGXrQrTy3acC6DknUA4idIVfg6gASASMHEpQeXU=; c=simple/simple; d=lists.sr.ht; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1713610034; v=1; b=Nh0JuPQbGa2DlN4n5s9f867myQzCD3eCR/D58dWtDoOEnX3NVcPpCilFak45zD0qaUeqMbAp 95ItFZZmz1YOmgE85cUbiuvp0IKTTdM8cC5WLin5+vMyHKu+mn9KDFigGypKChxajvOoPsLJ6HJ xpsidt26XafggV8d5TmBCzN4T++WVKtbQ3lx9EM5ki1LrJwnCDBaSXJFGExFhzwNsUEEGocsXfj 9Z/2TDWetOcgc0ynv1xI6lvRDv9ACUcR7nPGDp7Y4Ogyv+ejWlHmrFQEtpO/WA/AvJDyQMdyM2d dWTPBGXHhfp3hh6KlbNWuxWxlD727zUJ0PJaTbz2CzluQ== Received: from lists.sr.ht (unknown [IPv6:2a03:6000:1813:1337::154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 4D3E5203AB for ; Sat, 20 Apr 2024 10:47:14 +0000 (UTC) Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [IPv6:2001:41d0:1004:224b::bd]) by mail-a.sr.ht (Postfix) with ESMTPS id 92A2A2038A for <~johnnyrichard/olang-devel@lists.sr.ht>; Sat, 20 Apr 2024 10:47:13 +0000 (UTC) Date: Sat, 20 Apr 2024 13:45:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1713610031; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=neijiQqefHOFeBsaejTXgutlWH7mXrbW8lc6WJjzo8Q=; b=cvf0gB9CtWExivpLI+V/V0LXLvjqsgjNP06cWmqwGJalEXx3/y1AdzCBoECpTF47SUi/6n r1/io2NE4UEYIbpjkAQrULnnGJeePwdfPlqtq6KldznriK//t9/jKa3fZPrvtW9BXwfKnN DSnKaoVV0seygHAWIO+ylgDODcvDiLaRObQouYZhL/AHhXR0fmtLFmQi5TmLPxcbrozHAB 2PekaMm1e5vOMa81nB8NyeW3RXBIMFZCPz2Owpvi7qxbRqcYcFUzZTCj0MnPPVhJcVvyAe k518cA2KD9wutkN95L5sW4DZU/ui0YbMWQniYwGAxYiU8XSw4HPBjQ/Giuq+cw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Johnny Richard To: ricardo_kagawa@disroot.org Cc: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [RFC SPEC] Primitive data types and arrays Message-ID: References: <20240417013003.67442-1-ricardo_kagawa@disroot.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240417013003.67442-1-ricardo_kagawa@disroot.org> List-Unsubscribe: List-Subscribe: List-Archive: Archived-At: List-Post: List-ID: ~johnnyrichard/olang-devel <~johnnyrichard/olang-devel.lists.sr.ht> Sender: ~johnnyrichard/olang-devel <~johnnyrichard/olang-devel@lists.sr.ht> X-Migadu-Flow: FLOW_IN X-Migadu-Country: NL X-Migadu-Spam-Score: -10.14 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -10.14 X-Migadu-Queue-Id: 0457663E33 X-TUID: DWV8wMAYDITh On Tue, Apr 16, 2024 at 10:30:03PM -0300, ricardo_kagawa@disroot.org wrote: > > A olang array is just like a C array, no need to translation. Although it > > Are you sure about this? I mean, as a contiguous, properly sized chunk > of memory with indexed access, it looks fine. But in C, an array > variable is a pointer to that chunk of memory, and therefore pointer > arithmetics would be required to match C arrays. > > I'm not sure I'd like to deal with pointers. But it's not like I can't, > it's just that I know it opens a nasty can of worms that I'm not sure > you'd want to deal with as a language designer. I really would like to know what you see as nasty. I mean, don't you want to deal with pointer in general? Or you want to segregate the concept of array and pointers? > > > I loved it. Out of curiosity, we are going to have _boolean_ and _char_ > > > I believe. Shouldn't they also be included on these primitive spec? > > > > I like it! We could discuss in the near feature if they are or not just > > type alias for u8. But I also agree they must be built-in without the > > need of any include. > > I like the idea of treating `boolean` and `char` as primitives, but do > be careful about what they mean. > > Obviously, `boolean` can be either `true` or `false`, but what should > that mean? If `boolean` is mapped to `u8`, then zero and non-zero? That's what exactly what I had in mind. Which problems you see with this approach? > But the real question is what would `char` be? If the language should > support Unicode properly, then `char` would represent a _code unit_ > rather than a "character", which could be considered a misnomer. Since > Unicode uses variable-length characters, a Unicode character might be > difficult to represent as just `char`. > > If no Unicode support is planned, then `char` as `u8` is good enough to > represent characters in 7-bit ASCII encoding. Could you please enlighten me the implications of starting with `char` as `u8` alias (7-bit ASCII)? What are the problems we could have if we don't support Unicode properly? > > Let's go with _void_. We are on very early development stage, > > everything can change anytime. And _void_ is kind of very well known > > keyword. > > Note that in most languages where there is a `void` type, the `void` > type is not actually valid in variable declarations. They are valid only > in funtion return types. In C, they are also valid as pointer types > (that is, `void* x;` is valid), but IIRC, not as variable types > (`void x;` is not valid). I'm okay of not using void pointers as long as we have a replacement for it. I still want to have support to define a raw pointer (untyped). > In the current version of the spec, it would be included in > , rather than , to allow it only as a function > return type. Yeah, I like it. > Also, there are three other types that might be interesting, if I may > suggest: `never` (from TypeScript [1]), `unit` (from functional-like > languages [2]) and `null` (from ECMAScript specs [3]). > > [1]: https://www.typescriptlang.org/docs/handbook/2/functions.html#never > [2]: https://en.wikipedia.org/wiki/Unit_type > [3]: https://tc39.es/ecma262/multipage/overview.html#sec-null-value > > - `never` would not be that useful without an exception system. The language wont have exception. > - `null` would also be more interesting with union types (TypeScript), > to define nullable types as the union of a non-nullable type and the > `null` type. (C has union types, but they are not related to this.) > > - I don't really know why an empty tuple would be interesting as the > value for the `unit` type, but several languages use this convention. > In ECMAScript specs, there is a `null` type that uses the `null` > value as its unit value. I think this approach lead us to design a complex type system. I understand the value of this, but the cost is high when you want to design a simple language. Regarding `null` I would like to have `null` as an alias to 0 (zero). And we could also have semantic analyses on it. In this case `null` wont be a proper type.