Wiki

Ticket #27 (closed enhancement: fixed)

Opened 16 years ago

Last modified 15 years ago

Cobra native Language support for explicitly sized arrays

Reported by: hopscc Owned by: Chuck
Priority: major Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:

Description

Cobra needs to support natively the declaration of an array of a specific size (e.g 256 elements) mainly for easy interfacing with .NET
classes and methods that take arrays as buffers ( e.g for IO)

Currently Spec of an array size gives an error message
"Explicit array sizes are not currently supported."
have to fall back to C#.

see discussion  Explicit array sizes

Attachments

explicitArraySize.patch Download (4.7 KB) - added by hopscc 16 years ago.
patch for sized array as dcl type
explicitArraySizeErrorMod.patch Download (1.3 KB) - added by hopscc 16 years ago.
alternate patch indicating supported syntax
160-UseArrays.cobra Download (2.3 KB) - added by hopscc 16 years ago.
Arrays HowTo? example

Change History

Changed 16 years ago by hopscc

patch for sized array as dcl type

Changed 16 years ago by hopscc

explicitArraySize.patch is patch for providing sized arrays as declaration type
e.g.

buf as Byte[256]
intArr as int[10]

Changed 16 years ago by hopscc

alternate patch indicating supported syntax

Changed 16 years ago by hopscc

explicitArraySizeErrorMod.patch is alternate patch to the above.
If the sized array declaration is not supported this fixes the error message to
indicate the supported syntax

Changed 16 years ago by hopscc

  • owner set to Chuck
  • status changed from new to assigned

Changed 16 years ago by hopscc

Arrays HowTo? example

Changed 16 years ago by hopscc

Last File is an arrays example for the HowTos?.

Changed 15 years ago by Chuck

Check out the C# arrays tutorial at  http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx

It never shows an array size being part of the type. Also, the tutorial explicitly states early on:

"Another detail is that the size of the array is not part of its type as it is in the C language. This allows you to declare an array and assign any array of int objects to it, regardless of the array's length."

This is counter to the premise of this ticket's description that we need this syntax for "easy interfacing with .NET classes and methods that take arrays as buffers" since C# itself doesn't have this.

Also, arrays were already added to Cobra for easy interfacing with .NET classes and methods. Outside of multidim arrays (which are not common and possibly even non-existent in the .NET std lib), I don't know of any problems. If you know of a problem, please provide the code and the desired behavior.

The sample code with this ticket says:

lottaNums = int[](10)  # dynamic typing explicitly sized array

That's not dynamic typing. It's type inference equivalent to:

lottaNums as int[] = int[](10)

It *is* dynamically sized, but that's no different than C#:

int[] lottaNums = new int[10];

The Cobra syntax of "<array type>(<num args>)" follows all other object creation which is "<type>(<args>)".

I think all that's needed is a better error message saying that size is not part of the type, providing the syntax for creation.

There is a "fixed" modifier in C#. But that only works inside a class or struct which is why it's a modifier work instead of just plain array syntax. If we supported that, I think we'd have to do the same thing, but I've never needed it in C#. There are a host of C# features along those lines (another example is pointers) that have to do with interfacing with native DLLs and COM. Cobra doesn't embrace those features, instead relying on C# to be used for writing such wrappers.

Barring any further information, I don't anticipate adding fixed size array types. Again see  http://msdn.microsoft.com/en-us/library/aa288453(VS.71).aspx

Changed 15 years ago by hopscc

OK.
thats explicitArraySizeErrorMod.patch above then
You may feel the need to adjust the emitted text a little

Coupla points:
The tickets description and note about interfacing came from the issue that I couldnt find ANY way of creating an array of a size (for a sized buffer for .Net interfacing) beyond assignment from an initialized literal (that didnt seem reasonable for a reasonably sized buffer).

The obvious syntax (to me at least)

buffer as Byte[256]
# gives
# arr1.cobra(4): error: arr1.cobra(4,17): error: Explicit array sizes are not #currently supported.

# or even
buffer as Byte[](256)
# gives
#arr1.cobra(5): error: arr1.cobra(5,18): error: Unexpected call.


The first gives the impression that this capability isnt available yet but this is the right syntax

You did point out the correct syntax (in the forum discussion) but I misunderstood that (as intended rather than already implmenetd)
since I dont find that array decl syntax at all obvious
though perhaps it is intuitive to someone already intimate with C# or anyone not tainted by exposure to any other languages.

I'm not sure that quoting what c# does is any help since much of the rest of cobra is unlike what c# does (to its benefit).

I'm not after whatever the 'fixed' modifier does in C#

The second class of the sample code (BinaryFileReader?) is something along the lines of what I was trying to do. ( Use of supported syntax is obviously post all the above)

Changed 15 years ago by Chuck

  • status changed from assigned to accepted

The quoting of C# was in response to the "...for easy interfacing with .NET" portion of the description.

I'm updating the error message now.

Changed 15 years ago by Chuck

  • status changed from accepted to closed
  • resolution set to fixed

Also, what happens if you declare a var to be int[10] and then later try to assign int[](20) or int[](n) to it? The ticket doesn't say; maybe that information is in your patch.

Anyway, I updated the error message in changeset:1744 to say:

The size of the array is not part of its type. Specify the size when creating the array such as: [t.name]\[]([.peek.text]).

I may consider int[10] in the future for *creation*, but not for the type since the size isn't part of the type.

I won't likely make updates to arrays until I have time to consider:

  • multi-dim arrays
  • JVM arrays
  • syntactic shortcuts

...all together. That's a very low priority.

Note: See TracTickets for help on using tickets.