From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wBRCOSImH2aNCQAAqHPOHw:P1 (envelope-from ) for ; Wed, 17 Apr 2024 03:30:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id wBRCOSImH2aNCQAAqHPOHw (envelope-from ) for ; Wed, 17 Apr 2024 03:30:11 +0200 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=m0SPTGda; dkim=pass header.d=disroot.org header.s=mail header.b=gOCTozNq; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; dmarc=pass (policy=reject) header.from=disroot.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1713317410; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=tLkXGwRNloPBpUB+F8rA6gCjNz3/UwpK0NYEb50GbLk=; b=bY6EdtlK4xhZ5bNj8wfQyiEHlllLOQ/mFfqf+U2fVw80gfOOdjdlG5ZFx/3xKfTvraGN5c HVvPL7yNrmP0bJrg7j+Fp24HDYymttPJ9AwviTNVuflTSWRna6HbOmHWcjvDIxbBbHSvlq vqb/PyOYShaAEVJ1ZZOKkdcSWXJhl4CibxotATfOL+Trz1hMulMGUewRWALBrxfH/eIePa 18HQNPh+pQavaYLanOrd4XGqJG2aNUVEBkYVDFJtG71noPZIGQ0J3lFV0F0rDHg5G8NmFS Kn/iVAHPn+ADYDOD2S4MCB+qVd1IVCtlFCqO9BYNwrssHbHzdyYqO/CncdAPxg== ARC-Seal: i=1; s=key1; d=johnnyrichard.com; t=1713317410; a=rsa-sha256; cv=none; b=05OM2HkP940J5/eqAfX+YeS2zrRGqKzLt26uhzMHwVdsRhnLTsfG//3mBeIKQKmIxxcXoe jR9hyI6ANLLDH8XyJTNboTCuGA+/ztSl0/yREyVg4TujokrkEz32tONOEdcBvBQJUNTKgu U1DY5qUFJTnL8U0YBfLPNj+bFOV9HE+UVjwVvwIMRqbOhyT4hv/1MYqrGxiJt7Dz7r2joK C3aSKpJ55M4HCH2hN6sUMj3130O4Dp8VmVvmoqlTJiKYYYNJvRvRPTRsjcaEtUuqfremPx 2rrSMIuHCOklQ5KkNBeSBFTcd8WHSjayO/VxWLyv+1zcQ6qMen+GDgSHQAudaw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=m0SPTGda; dkim=pass header.d=disroot.org header.s=mail header.b=gOCTozNq; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; dmarc=pass (policy=reject) header.from=disroot.org 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 B1F1563FEC for ; Wed, 17 Apr 2024 03:30:10 +0200 (CEST) DKIM-Signature: a=rsa-sha256; bh=hpH/kwGoWh0pB/jpm1S5K2rDOD+Npo90h55YAzWZjxc=; c=simple/simple; d=lists.sr.ht; h=From:To:Subject:Date:In-Reply-To:References:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1713317410; v=1; b=m0SPTGdatIWLrR82mmHDrEdGYoMYisQdhlcGpdBEGCqZYxG0elrtyo90/v/lcpAuz1NtyysY 9tTX7aq6pRQc3fW5ZArrKiZBztFF91PWL1d8bQ3tZYy/ME8+cvWTM2VkonrchfzQ+4W+EofOiV/ oafvm1gBcYI9WLUKrTVsKMEp9fjQ3Vx5vnKcgCbREBI4X8kpfhuKLWsEYHuyrvp+TlY7ac7QCM+ fAIk8IAxI1ZKxhpoa5YQngg6KBS04OQleUJ+YUM+TLB1+0+nql2tfdZniI4hwNcXdZYjT+fmwfL MDnqttkkNKa8UR5+nq0XgEgMWU0tFWOcvPAT4z3F9OIgA== Received: from lists.sr.ht (unknown [IPv6:2a03:6000:1813:1337::154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 62C4F20198 for ; Wed, 17 Apr 2024 01:30:10 +0000 (UTC) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) by mail-a.sr.ht (Postfix) with ESMTPS id AEBC520189 for <~johnnyrichard/olang-devel@lists.sr.ht>; Wed, 17 Apr 2024 01:30:09 +0000 (UTC) X-Virus-Scanned: SPAM Filter at disroot.org From: ricardo_kagawa@disroot.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1713317408; bh=hpH/kwGoWh0pB/jpm1S5K2rDOD+Npo90h55YAzWZjxc=; h=From:To:Subject:Date:In-Reply-To:References; b=gOCTozNqbpN9kA1suEyHp/VGWT+l5tswJcDe3NW2OSZkePZCIjSH7Ax0vPfsNOYNW mLYe1LS9M4qmi3uIkj9t7lGNiUHlJWNlxy1tYXTE5y+LywiK8yjFEwyD2bm5Zp1UPG qubXUCJVdfkcUDmf6Fk0l4YhtB2qhgGp29TNry4OgNKCmnB5nD1KbTcCfna3+rSxrR iKZ5k2a4r6M4pD5J+b+QKsoKmRjjz1GsCXPqy9ciRw1+MBCc8eWNtFP+BDkr34F9EL 3CfsLwxkxPDW1XRTDwEjc1d16MvnzHFP4k5Oq5KE38E5hKkX+P4bezMMzZEdHOMIfw +zmdn51dBUfBg== To: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [RFC SPEC] Primitive data types and arrays Date: Tue, 16 Apr 2024 22:30:03 -0300 Message-ID: <20240417013003.67442-1-ricardo_kagawa@disroot.org> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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-Country: NL X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.11 X-Spam-Score: -9.11 X-Migadu-Queue-Id: B1F1563FEC X-Migadu-Scanner: mx13.migadu.com X-TUID: wY1ItswDrBAv > 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 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? 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. > > Perhaps _char_ SHOULD have support to escaped chars like \r (carried > > return), \n (line feed)... Whenever you create the patch, don't forget it. > > Sure! I will cover this. Thanks! If you have plans to support Unicode, then I'd also suggest to include hexadecimal and Unicode escapes, like `\x20` and `\uffef`. > > > I am wondering if we should also define _void_ as a primitive. > > > > I think so. Do you like the name *void*? I don't like that much by I > > can't think in any alternative. > > 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). In the current version of the spec, it would be included in , rather than , to allow it only as a function return type. 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. - `unit` and `null` would not make much sense at the same time, so it is either one or the other. - `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.