Omnimaga: The Coders Of Tomorrow
Welcome, Guest. Please login or register.
 
Omnimaga: The Coders Of Tomorrow
23 May, 2013, 15:44:11 *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   home   news downloads projects tutorials misc forums rules new posts irc about Login Register  
+-OmnomIRC

You must Register, be logged in and have at least 40 posts to use this shout-box! If it still doesn't show up afterward, it might be that OmnomIRC is disabled for your group or under maintenance.

Note: You can also use an IRC client like mIRC, X-Chat or Mibbit to connect to an EFnet server and #omnimaga.

Pages: 1 ... 4 5 [6] 7 8 ... 11   Go Down
  Print  
Author Topic: Antelope (formerly "OPIA") - A Polymorphic z80 language -  (Read 5448 times) Bookmark and Share
0 Members and 1 Guest are viewing this topic.
shkaboinka
LV3 Member (Next: 100)
***
Offline Offline

Gender: Male
Last Login: 27 October, 2012, 10:26:56
Date Registered: 15 July, 2011, 15:14:52
Location: Spokane, WA
Posts: 83

Topic starter
Total Post Ratings: +9

View Profile WWW
« Reply #75 on: 25 March, 2012, 00:44:22 »
+1

I must have had too much radiation for breakfast...EVEN MORE Recent Updates (Note: I had to use "d,e,f" instead of "a,b,c" or "x,y,z" because those turn into tags):

There has been discussion about using an [d,e,f] syntax for multidimensional arrays like in C# (These would be TRULY multidimensional, rather than being arrays of pointers to arrays, etc.). This sparked a lot of possible changes, which I am just going to paste in here:

I'd like to consider something similar for OPIA, but there are some issues that would need addressing if I do: (1) To keep [,] rectangular (versus the jagged [][]), There would have to be a way to embed (or specify) size information (OPIA does not currently do this for native-compatibility reasons). (2) To avoid ambiguity, [d][e] should mean something different than [d,e]. ... Let's look at this step by step so we can decide on a good setup altogether:


1
2
3
4
5
6
7
8
9
10
11
// Current setup:

[]byte // Points to a byte-array
[5]byte // IS a (static) byte-array (5 values)
[_]byte // Same as above, but size is determined from usage
*[5]byte // Same as []byte, but requires/assumes the underlying array is 5 bytes

[5][5]byte // An array of five [5]byte values (no pointers!)
[5][]byte // (static) Array of five []byte values (five pointers)
[][5]byte // Points to an array of five [5]byte values
[][]byte // Points to an array of pointers to arrays

I could deal with (issue 1) by providing a way to explicitly embed size information at the front of an array:


1
2
3
4
// Hypothetical way to embed size-information:
[byte]byte // A (static) byte-array, prefixed by a byte to store the size
[word]byte // A (static) byte-array, prefixed by a word to store the size
*[byte]byte // Pointer to such an array

I could deal with (issue 2) by making every inner set of square brackets [...] become a pointer (e.g. make [d][e] ALWAYS "jagged" and [d,e] ALWAYS rectangular); and for symmetry, I could have the outermost [...] ONLY be a pointer if the * is used. It would like like this (I will just say "array" for "static array", and "pointer to array" otherwise):


1
2
3
4
5
6
7
8
9
10
11
12
13
14
[]byte // Array of (some determinable number of) bytes (previously indicated as [_]byte)
[5]byte // Array of 5 bytes
[byte]byte // Array of bytes (prefixed with a byte to indicate the size)

*[]byte // Pointer to an array of bytes
*[5]byte // Pointer to an array of 5 bytes
*[byte]byte // Pointer to a (byte-) size-prefixed array of bytes

[][]byte // Array of *[]byte values.
[5][5]byte // Array of five *[5]byte values.
[5,5]byte // Array of five [5]byte values (no pointers)
[5][5,5]byte // Array of five *[5,5]byte values
[5,5,5,5]byte // A 4-Dimensional array of bytes (no pointers)
[5,5][5,5]byte // 2D array of pointers to [5,5]byte values

This seems all well and good so far ([]T has become *[]T, but [5]*[5]T has also become just [5][5]T, and [5][5]T has become [5,5]T). However, since you cannot even COMPUTE a 2D index without at least knowing the inner-most dimensions of a multidimensional array (since it is all internally stored as a 1D array), you would have to specify (at least some of) the dimensions when working with pointers:


1
2
3
4
5
6
[,]byte // Static 2D array (NOTE: the sizes have to be determinable!)
*[,]byte // ERROR! (cannot even COMPUTE where [d,e] is without the inner dimension)
*[,5]byte // Pointer to a [?,5]byte (ok: [d,e] is [5*d+e])
*[,byte]byte // (also ok, since [d,e] is [SIZE*d+e], and size is stored as a leading byte)
*[byte,]byte // ERROR! (It's the inner dimension that matters)
*[5,5]byte // Pointer to a [5,5]byte -- Very ok

I'd be ok with allowing a multidimensional array to be treated as an array with fewer dimensions:


1
2
3
4
5
6
7
8
9
[3,4,5]byte arr;
*[3,4,5]byte p3 = &arr; // p3[d,e,f] refers to arr[d,e,f]
*[,5]byte p2 = &arr; // treat arr as a [12,5]byte (e.g. p2[4*d + e, f])
*[]byte p1 = &arr; // treat arr as a [60]byte (e.g. p1[5*4*d + 5*e + f])

// I'd like NOT to allow this:
arr[d] // gives the dth [4,5]byte value
arr[d,e] // gives the [d,e]th [5]byte value
// ... because it means that arr[d][e][f] is the same as arr[d,e,f]
« Last Edit: 26 March, 2012, 15:22:50 by shkaboinka » Logged
Pages: 1 ... 4 5 [6] 7 8 ... 11   Go Up
  Print  
 
Jump to:  

Powered by EzPortal
Powered by MySQL Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Powered by PHP
Page created in 0.272 seconds with 31 queries.
Skin by DJ Omnimaga edited from SMF default theme with the help of tr1p1ea.
All programs, games and songs avaliable on this website are property of their respective owners.
Best viewed in Opera, Firefox, Chrome and Safari with a resolution of 1024x768 or above.