|
|
 Up |
|
|
  |
Author: James GilesJames Giles Date: Jun 8, 2008 12:32
> there will be exactly one intrinsic structure - the array - of
> exactly two types - statically sized (known at compile time) and
> dynamically sized (known at the time of entry into a subprogram.
>
> Static versus dynamic need not be declared - the compiler should be
> able to infer it. Exiting from a sub-program deallocates all arrays
> that are not present in the argument list.
>
> memory management will not be done through program statements.
In other words, no dynamic memory. (What you're calling "dynamic"
is either "assumed shape" for dummy arguments, or it's "automatic"
for local arrays in a procedure. Neither is really dynamic memory).
And you have no strings. So that means no concatenation, no
lexical compares, etc. Are whole-array assignments permitted?
If so, what's the rule if the left side is different size than the
right? If it's automatically pad/truncate the data to fit: bletch.
|
| Show full article (1.46Kb) |
|
| | 50 Comments |
|
|
Author: analyst41analyst41 Date: Jun 8, 2008 15:16
On Jun 8, 3:32 pm, "James Giles" worldnet.att.net> wrote:>> there will be exactly one intrinsic structure - the array - of
>> exactly two types - statically sized (known at compile time) and
>> dynamically sized (known at the time of entry into a subprogram.
>
>> Static versus dynamic need not be declared - the compiler should be
>> able to infer it. Exiting from a sub-program deallocates all arrays
>> that are not present in the argument list.
>
>> memory management will not be done through program statements.
>
> In other words, no dynamic memory. (What you're calling "dynamic"
> is either "assumed shape" for dummy arguments, or it's "automatic"
> for local arrays in a procedure. Neither is really dynamic memory).
>
|
| Show full article (2.87Kb) |
|
| | 1 Comment |
|
|
Author: James GilesJames Giles Date: Jun 8, 2008 15:55
> On Jun 8, 3:32 pm, "James Giles" worldnet.att.net> wrote:...
>> In other words, no dynamic memory. (What you're calling "dynamic"
>> is either "assumed shape" for dummy arguments, or it's "automatic"
>> for local arrays in a procedure. Neither is really dynamic memory).
>>
>
> Got it.
>
> Can we be assured of no memory leakage with this specification of the
> types of arrays allowed?
Obviously. But Fortran's allocatable also guarantees no
memory leaks. And it *is* a form of dynamic memory.
|
| Show full article (2.65Kb) |
| no comments |
|
|
Author: analyst41analyst41 Date: Jun 9, 2008 03:31
On Jun 8, 6:55 pm, "James Giles" worldnet.att.net> wrote:>> On Jun 8, 3:32 pm, "James Giles" worldnet.att.net> wrote:> ...
>>> In other words, no dynamic memory. (What you're calling "dynamic"
>>> is either "assumed shape" for dummy arguments, or it's "automatic"
>>> for local arrays in a procedure. Neither is really dynamic memory).
>
>> Got it.
>
>> Can we be assured of no memory leakage with this specification of the
>> types of arrays allowed?
>
> Obviously. But Fortran's allocatable also guarantees no
> memory leaks. And it *is* a form of dynamic memory.
>
> ...
>
>> whole array operations will be the core of the language. I am open as
>> to strings, except I am a little confused what a string ought to be. ...
|
| Show full article (3.79Kb) |
| 1 Comment |
|
|
Author: James GilesJames Giles Date: Jun 9, 2008 10:51
> On Jun 8, 6:55 pm, "James Giles" worldnet.att.net> wrote:...
> I'd like to nail down the features of strings first:
>
> (1) How should they be declared? Integers, Floats logicals and
> character will be declared exactly as in fortran. I guess
>
> String a,b,c
>
> would be the most natural way to declare a b and c to be string
> identifiers.
Oh that's right. In order to make the code harder to read
you don't want attributes to be expressed at the same time
as type. So you have to have a separate statement which
requires users to look all around for things instead of
looking in just one place. I'd prefer:
|
| Show full article (2.98Kb) |
| no comments |
|
|
Author: GaryScottGaryScott Date: Jun 9, 2008 11:23
On Jun 9, 12:51 pm, "James Giles" worldnet.att.net> wrote:>> On Jun 8, 6:55 pm, "James Giles" worldnet.att.net> wrote:> ...
>> I'd like to nail down the features of strings first:
>
>> (1) How should they be declared? Integers, Floats logicals and
>> character will be declared exactly as in fortran. I guess
>
>> String a,b,c
>
>> would be the most natural way to declare a b and c to be string
>> identifiers.
>
> Oh that's right. In order to make the code harder to read
> you don't want attributes to be expressed at the same time
> as type. So you have to have a separate statement which
> requires users to look all around for things instead of
> looking in just one place. I'd prefer:
> ...
|
| Show full article (2.18Kb) |
| no comments |
|
|
Author: analyst41analyst41 Date: Jun 9, 2008 11:41
On Jun 9, 1:51 pm, "James Giles" worldnet.att.net> wrote:>> On Jun 8, 6:55 pm, "James Giles" worldnet.att.net> wrote:> ...
>> I'd like to nail down the features of strings first:
>
>> (1) How should they be declared? Integers, Floats logicals and
>> character will be declared exactly as in fortran. I guess
>
>> String a,b,c
>
>> would be the most natural way to declare a b and c to be string
>> identifiers.
>
> Oh that's right. In order to make the code harder to read
> you don't want attributes to be expressed at the same time
> as type. So you have to have a separate statement which
> requires users to look all around for things instead of
> looking in just one place. I'd prefer:
> ...
|
| Show full article (4.65Kb) |
| no comments |
|
|
Author: analyst41analyst41 Date: Jun 9, 2008 11:44
On Jun 9, 2:23 pm, GaryScott sbcglobal.net> wrote:> On Jun 9, 12:51 pm, "James Giles" worldnet.att.net> wrote:
>
>
>
>
>>>> On Jun 8, 6:55 pm, "James Giles" worldnet.att.net> wrote:>> ...
>>> I'd like to nail down the features of strings first:
>
>>> (1) How should they be declared? Integers, Floats logicals and
>>> character will be declared exactly as in fortran. I guess
>
>>> String a,b,c
>
>>> would be the most natural way to declare a b and c to be string
>>> identifiers.
> ...
|
| Show full article (2.65Kb) |
| no comments |
|
|
Author: James GilesJames Giles Date: Jun 9, 2008 12:18
GaryScott wrote:
> On Jun 9, 12:51 pm, "James Giles" worldnet.att.net> wrote:...
>> character, string :: a
>> integer, string :: b
>> etc.
>
> Sorry, I missed something. What is an integer string? Is that an
> array of integers of default size that holds characters?
A string is a collection of data whose length is determined
at assignment, concatenate is defined on it, and comparisons
are lexicographic (that is, an element at a time until you find
a difference). You should be allowed strings of *any* base
type. Or is it that you don't think integers can need to be
in collections?
|
| Show full article (1.52Kb) |
| no comments |
|
|
|
|
|
Author: James GilesJames Giles Date: Jun 9, 2008 12:40
> I suddenly realized that you are suggesting strings of all the
> primitive types - that makes the notion of string "length"
> meaningless.
Why would "length" be an inappropriate term? It corresponds
to SIZE of an array. (Maybe both should be called SIZE.) There
are very few differences between strings and rank-1 arrays.
> I also want to be able to say string = '' to empty a char string. If
> I have understood you correctly , a better way would be a statement
> assigning zero cardinality to be able to empty out any type of string.
For the base type CHARACTER, I see no reason that str=''
shouldn't work. I think a constructor for strings of other
base types should just be a parenthetical list. So:
myIntStr = ()
That would make a null string for base type INTEGER.
> I can't even begin to think of uses for strings of integers or reals
> (distinct from rank 1 arrays) - what did you have in mind with respect
> their usefulness ?
|
| Show full article (2.70Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
