From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 2Di6FvbVGGalBwAAqHPOHw:P1 (envelope-from ) for ; Fri, 12 Apr 2024 08:34:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2Di6FvbVGGalBwAAqHPOHw (envelope-from ) for ; Fri, 12 Apr 2024 08:34:30 +0200 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=XAU848sE; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=EaaBnnCj; 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=1712903670; a=rsa-sha256; cv=none; b=0lE8oY0Vnw2oYGzKWS13d0WGIKMedGLJR46dDducyX8PFf4e1rCOWoD87wPSZumFMJls3z aF8y0C6z/moSIV+mYO6MxjAAK2kGQzKyitesRNk3YxO/Pw8iyGeXAqOABVIjSeGUDA3NOT 0jeXsrr5vO8xNCVhnGAB7aLpxLFKTpHhdRezs7x/TxCgju8q+VIcwYhj5JMy5WwWRDISsa N2XDmc8HsDhYxD/+e4Nb3rJ8Zy9P/IBTWdBhrE3beopnlELwUBteVC6d+X3/f/vPWV3Mt6 bFtnT1Jzr8zTrHA3vnJp0Xl5NxVuZUVyOweHg0j3aO+h5Af1Mc4XbgYlGt0CYA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=XAU848sE; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=EaaBnnCj; 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=1712903670; 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: 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=Tj1n4a9+gs1UaiQf3rRThQ4PWzvH8VLEXd1OgZqJNIc=; b=1etCEVA5UP5NGJBjUEbpYWhRH1JQ0ReeUtOMXRzR4mmCa7TOGz+HJt79jGJUftmdQjrW8w /vY9KB0nF5M7EPCn3138ZbhA9T+q1XsTsaMFRvfDDy9qBSB28ivAMvO3Ky7Mt30bQ1/ISc rj1Q71FtCkYPWGdszR1cT6rjO16Yv/2Ak7JX5pwxEw7T0NCqX8YvTYRpEe4chfeoL9rIlV eHXKLbquLLTogFA/8u/irnUHcB5X3kt+msiK56Krr3AZBHATp1o8sBFqGAkzMJeashuCpr PKfU63tVRVgqx4xrAFEfdSEGS/ivmLBx9atYP2mbh9wDaS1pxaDp9faFIHbeXg== 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 4992A70F01 for ; Fri, 12 Apr 2024 08:34:27 +0200 (CEST) DKIM-Signature: a=rsa-sha256; bh=zGU+OHE7U5FPw3ZPaDA2r7yqQwPHapZ3hg7mi71Wzno=; 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=1712903666; v=1; b=XAU848sE5w5JfQQZvYpa5u3boyFZkcmMMCX4wg3POyDG8IiKbkOCMuhB+7yun+PFPo+Vd7Xk cctHz4gJtS+Kg/e1tmegwLGc1eNUfk6HE8ioweTBji6PNDv47lsRRzCuv3LAGpkg8L1qBrPGz47 nmEqmgwsef43AZaF3j/CLGNir8YtGoU3ZBoIJwLZnnuvXGPuba4dMYBu654KDP5V/yzk00rY4iu NSnlKJyhPq1r1Gt705++Fl1h9DVnrzy0iFMlOUm+bedVppQlWlKdKFPjjhViHeDsD+asdWkiQUY ABsO7vPxCaaucWtP/1UKYdKcxVMs7PC744yIIx9K+YAug== Received: from lists.sr.ht (unknown [IPv6:2a03:6000:1813:1337::154]) by mail-a.sr.ht (Postfix) with ESMTPSA id C137820516 for ; Fri, 12 Apr 2024 06:34:26 +0000 (UTC) Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [IPv6:2001:41d0:1004:224b::b1]) by mail-a.sr.ht (Postfix) with ESMTPS id 2206C204ED for <~johnnyrichard/olang-devel@lists.sr.ht>; Fri, 12 Apr 2024 06:34:26 +0000 (UTC) Date: Fri, 12 Apr 2024 09:32:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1712903665; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tj1n4a9+gs1UaiQf3rRThQ4PWzvH8VLEXd1OgZqJNIc=; b=EaaBnnCjIv97yylomvtbbW2eB662CxpFzIAe/Y/+9B7wcRGqm+n4WbQ/qydvyHCnx3Vq7R IvQEvLCcFkMioXQIY2DKXPbYxQdBYFMtHRRYnXewD0vCjVeNDEgwkJrzdxZ79x6SpeQdcJ wO0c6POrjECT366G10Sj8kGJQ5mtEopw++pWTHl+hCoGBCAMq1ZlIS2zC4Cflgv+deRTWu NYUwvlVbyvWEp3j6cMwshpwYWbf4/qBFX065FMfphgl74TKDK7GnuGiP6pS75KFyosNUqZ +0SXU3W1xJDd/Bp/a0PCyEruagfYELSuuV/ytneTEbv3g260ajB9N6j+AQ9rww== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Johnny Richard To: Carlos Maniero Cc: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [RFC SPEC] Primitive data types and arrays Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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-Spam-Score: -10.13 X-Migadu-Queue-Id: 4992A70F01 X-Migadu-Spam-Score: -10.13 X-Migadu-Scanner: mx10.migadu.com X-TUID: g+HkCixvFa9a On Mon, Apr 08, 2024 at 12:29:11AM -0300, Carlos Maniero wrote: > This thread tries to specify a basic datatypes of olang. > > Primitive data types: > ===================== > > Primitive types are types that can be held on a general purpose register. > > s8 : 8-bit signed integer type. > s16 : 16-bit signed integer type. > s32 : 32-bit signed integer type. > s64 : 64-bit signed integer type. > u8 : 8-bit unsigned integer type. > u16 : 16-bit unsigned integer type. > u32 : 32-bit unsigned integer type. > u64 : 64-bit unsigned integer type. > f32 : 32-bit floating point type. > f64 : 64-bit floating point type. > > Translation to C: > ----------------- > > s8 : int8_t > s16 : int16_t > s32 : int32_t > s64 : int64_t > u8 : uint8_t > u16 : uint16_t > u32 : uint32_t > u64 : uint64_t > f32 : int32_t > f64 : int64_t 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? > C also permits the use of type qualifiers, such as signed int or short int. > However, this specification recommends omitting the qualifier for simplicity. > In my opinion, this approach is more intuitive. While the meaning of long int > can be ambiguous, there’s no ambiguity with int32_t. I agree. > Arrays: > ======= > > An array is a fixed-size collection of similar data items stored in contiguous > memory locations. It can be used to store the collection of primitive data > types such as int, char, float, etc., and also derived and user-defined data > types, structures, etc. > > Example: > -------- > > const x: u32[] = [1] > const y: u32[2] = [1, 2] > > Grammar: > -------- > > ::= '[' * ']' > ::= '[' > > ( > ( ',' )* > )? > > ']' > > Open question: > -------------- > > I have no idea how to initialize an array with a value. In C I know that this > is allowed: > > int arr[20] = {0}; > > But I think this is ambiguous since if I remove the number 20 from the > statement above it will give me an one-sized array. Yeah, I see... With the syntax you proposed I suggest the following syntax for initialize all elements zeroed: const arr: u8[2] = [...0] It should only work for arrays with size explicitly declared. > Translation to C: > ----------------- > > A olang array is just like a C array, no need to translation. Although it > differs from C by using square brakets other then curly brakets. That way we > could easily differ arrays from structs. Sure. I like it. I think we can split this RFC up into different RFCs. One for discuss primitive types and another one for discussing arrays in general. What do you think? There is other topics we also can discuss about arrays, for example: Array access by index --------------------- The brackets in C has weird behaviour on arrays when accessed by index as listed bellow: int xs[] = { 1, 2 }; xs[0] = 1; 0[xs] = 1; xs[1] = 2; 1[xs] = 2; The weird array access with the number as the first element works because c does pointer arithmetics in the end. xs[i] == *(xs + 1) [i]xs == *(i + xs) I like the C simplicity of translating it to pointers arithmetics, but I think the access using number first is too weird. We should avoid it I believe.