1. [POLL] Typing elements within a Type
Hello all
The next poll is presented below.
There is no strict time limit on the poll. You can argue as long as you want,
but please do so in a different thread from this POLL thread. If you want to make
sure I allow enough time, just say clearly in this thread what you want (and post
your arguments elsewhere).
Votes in the poll are limited to the specific questions asked.
1. Do you support the introduction of syntax in one of the following forms to
allow a programmer to declare the types of elements within a user-defined type
based on a sequence?
[ANSWER YES OR NO]
Variation A1:
type customer( sequence x )
fields
integer x[1]
sequence x[2]
sequence x[3]
end fields
-- insert other code here
end type
Variation B1:
type customer( sequence x )
fields
integer -- x[1] is assumed
sequence -- x[2] is assumed
sequence -- x[3] is assumed
end fields
-- insert other code here
end type
2. Regardless of your answer to the previous question:-
(a) which variation do you prefer? {ANSWER A1 or B1]
(b) would you support the introduction of both together?
[ANSWER YES OR NO]
3. Regardless of your previous answers, do you support the introduction of
syntax of the same kind but with naming of elements, like this:
[ANSWER YES or NO]
Variation A2:
type customer( sequence x )
fields
integer x[1] id
sequence x[2] name
sequence x[3] address
end fields
-- other code here
end type
Variation B2:
type customer( sequence x )
fields
integer id -- x[1] is assumed
sequence name -- x[2] is assumed
sequence address -- x[3] is assumed
end fields
-- other code here
end type
4. Regardless of your answer to the previous question:-
(a) which variation do you prefer? {ANSWER A2 or B2]
(b) would you support the introduction of both together?
[ANSWER YES OR NO]
5. Regardless of your previous answers, if syntax with naming were introduced,
would you prefer the elements in an object declarded with this type to be
accessible by:- [ANSWER a or b]
(a) dot access e.g. customer_x.name; or
(b) subscript/indexes e.g. customer_x[name]
6. Regardless of your previous answers, if such syntax were introduced (with or
without naming), would you prefer it to imply: [ANSWER a or b]
(a) length(x) = 3 -- the interpreter would enforce this
-- or merely
(b) length(x) >= 3?
COMMENTS:
The questions have been derived from a thread started by Salix on 19/8/07
entitled "Type - Start Again". Since that thread, a poll has supported the
introduction of syntax like the following (though not yet implemented):
sequence of integer
sequence of sequence of integer
If introduced, such syntax could be available in the examples either in the
parameter of the type or in the field block. E.g.
type customer( sequence of sequence x ) -- etc
-- OR
type customer( sequence x )
fields:
sequence of integer x[1] -- or equivalent for variation B.
-- etc
This may be relevant to your consideration of the questions.
Regards
Peter Robinson
2. Re: [POLL] Typing elements within a Type
Peter Robinson wrote:
1. NO
2(a). B1
2(b). NO
3. YES
4(a). B2
4(b). NO
5. a
6. a
In summary, I would support only Named fields whose index was implied by its
lexical ordering in the declaration, and access to those fields would be via
'dot' notation. Structures that are declared using fields should be limited to
containing only those fields and not extra elements.
Because Names rather than numbers, make it easier to document and write with
less errors. The 'dot' notation helps keep the scope of the field names linked to
the structure's declaration - it is less ambiguous for the interpreter to workout
how to reference the field you are after.
However, normal index notation should also be allowed to access the fields in
the structure.
Thus
cust.name = "Derek"
and
cust[1] = "Derek"
should be equivalent.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
3. Re: [POLL] Typing elements within a Type
1. YES
2a. B1
2b. NO
3. YES
4a. B2
4b. NO
5. (a)
6. see below
With regard to item 5, I agree with Derek: the field name should take a dot, but
[] could also be used with a numeric index.
I strongly believe that the programmer should have the option to enforce whether
variable length is allowed or not. What I have in mind would be the analog of
Ruby's * prefix for the last argument in an argument list.
A possibility would be
type foo (sequence x)
fields
integer q
string r
*sequence s
end fields
end type
to indicate that s is to be assigned x[3..$].
Other notations are possible and a word, perhaps "collect", would be more
Euphoric than * or any other symbol:
2a. B1
2b. NO
3. YES
4a. B2
4b. NO
5. (a)
6. see below
With regard to item 5, I agree with Derek: the field name should take a dot, but
[] could also be used with a numeric index.
I strongly believe that the programmer should have the option to enforce whether
variable length is allowed or not. What I have in mind would be the analog of
Ruby's * prefix for the last argument in an argument list.
A possibility would be
type foo (sequence x)
fields
integer q
string r
collect s
end fields
end type
4. Re: [POLL] Typing elements within a Type
1. Yes
2(a). A1
2(b). No
3(a2) Yes
3(b2) No
4(a) A2
4(b) No
5 B
6 A
5. Re: [POLL] Typing elements within a Type
Peter Robinson wrote:
> 1. Do you support the introduction of syntax in one of the following forms to
> allow a programmer to declare the types of elements within a user-defined type
> based on a sequence?
> [ANSWER YES OR NO]
>
> Variation A1:
>
> type customer( sequence x )
> fields
> integer x[1]
> sequence x[2]
> sequence x[3]
> end fields
> -- insert other code here
> end type
>
>
> Variation B1:
>
> type customer( sequence x )
> fields
> integer -- x[1] is assumed
> sequence -- x[2] is assumed
> sequence -- x[3] is assumed
> end fields
> -- insert other code here
> end type
>
NO
> 2. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? {ANSWER A1 or B1]
>
B1
> (b) would you support the introduction of both together?
> [ANSWER YES OR NO]
YES
>
> 3. Regardless of your previous answers, do you support the introduction of
> syntax
> of the same kind but with naming of elements, like this:
> [ANSWER YES or NO]
>
> Variation A2:
>
> type customer( sequence x )
> fields
> integer x[1] id
> sequence x[2] name
> sequence x[3] address
> end fields
> -- other code here
> end type
>
>
> Variation B2:
>
> type customer( sequence x )
> fields
> integer id -- x[1] is assumed
> sequence name -- x[2] is assumed
> sequence address -- x[3] is assumed
> end fields
> -- other code here
> end type
>
YES
> 4. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? {ANSWER A2 or B2]
>
B2
> (b) would you support the introduction of both together?
> [ANSWER YES OR NO]
>
YES
> 5. Regardless of your previous answers, if syntax with naming were introduced,
> would you prefer the elements in an object declarded with this type to be
> accessible
> by:- [ANSWER a or b]
>
> (a) dot access e.g. customer_x.name; or
>
> (b) subscript/indexes e.g. customer_x[name]
>
a
> 6. Regardless of your previous answers, if such syntax were introduced (with
> or without naming), would you prefer it to imply: [ANSWER a or b]
>
> (a) length(x) = 3 -- the interpreter would enforce this
>
> -- or merely
>
> (b) length(x) >= 3?
>
b
> Regards
> Peter Robinson
CChris
6. Re: [POLL] Typing elements within a Type
1 yes
2a A1
2b no
3 yes
4a A2
4b no
5 b
6 b
Rgds,
Salix
7. Re: [POLL] Typing elements within a Type
- Posted by Peter Robinson <indorlaw at y?hoo.com?au>
Aug 29, 2007
-
Last edited Aug 30, 2007
Hi all
Not many voters so far. No problem if you want to leave it to others, but I'll
keep it open for a while, just in case. In the past, quite a few have been
interested in this kind of proposal.
Cheers
Peter Robinson
8. Re: [POLL] Typing elements within a Type
- Posted by c.k.lester <euphoric at ?kles?er.com>
Aug 29, 2007
-
Last edited Aug 30, 2007
Peter Robinson wrote:
>
> 1. Do you support the introduction of syntax in one of the following forms to
> allow a programmer to declare the types of elements within a user-defined type
> based on a sequence?
> [YES]
>
> 2. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? [B1]
>
> (b) would you support the introduction of both together?
> [NO]
>
> 3. Regardless of your previous answers, do you support the introduction of
> syntax
> of the same kind but with naming of elements, like this:
> [YES]
>
> 4. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? [B2]
>
> (b) would you support the introduction of both together?
> [NO]
>
> 5. Regardless of your previous answers, if syntax with naming were introduced,
> would you prefer the elements in an object declared with this type to be
> accessible
> by:- [a]
>
> 6. Regardless of your previous answers, if such syntax were introduced (with
> or without naming), would you prefer it to imply: [a]
Make it so. ;)
9. Re: [POLL] Typing elements within a Type
Peter Robinson wrote:
> Not many voters so far. No problem if you want to leave it to others, but I'll
> keep it open for a while, just in case. In the past, quite a few have been
> interested
> in this kind of proposal.
I'll vote within a few days.
I just haven't had time to think about it yet.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: [POLL] Typing elements within a Type
Thanks Rob. I'll certainly keep it open at least until then,
Cheers
PR
11. Re: [POLL] Typing elements within a Type
Hello Peter,
I've already voted but there a few things I'm not sure I understood correctly.
== 2nd question ==
I voted for A1 but do I understand right that A1 would allow me to define
things also this way?
Variation A1 (modified)
type customer( sequence x )
fields
integer x[1]
sequence x[2]
sequence x[3]
atom x[3][1]
integer x[3][2]
atom x[3][3]
end fields
-- insert other code here
end type
What do you mean by "other code"? Wouldn't you (we 
) want to allow
this syntax?
Variation A1 (modified)
type customer( sequence x )
fields
integer x[1]
sequence x[2]
sequence x[3]
x[1]>0
x[1]<100
end fields
-- insert other code here
end type
I don't think that the clarification would influence my answer given earlier
but might be useful information for others. It might also help me to understand
what to expect. (What about B1?)
== 3rd question ==
I voted for A2 but does it also meant that you can use it like this?
Variation A2 (modified)
type customer( sequence x )
fields
integer x[1] id
sequence x[2] name
sequence x[3] address
atom x[3][1] ZIP --
integer x[3][2] nr -- house nr
atom x[3][3] floor
end fields
-- other code here
end type
customer x
x={0,"",{0,0,0}}
x[id]=1
x[name]="Szabó András"
x[address][ZIP]=2475
x[address][nr]=18
x[address][floor]=1
Again, I don't think your explanation will change my vote, it's just that
I want to have a clear picture what we're taliking about and possibly help
the future voters. (What about B2?)
Thanks in advance!
Salix
12. Re: [POLL] Typing elements within a Type
Hi Salix
I deliberately limited these questions to typing and aliasing the first
dimension i.e. x[1..$] and did not include the variations for typing deeper
dimensions or the one along the lines that boolean expressions could be expressed
in short-hand assertions something like this -
length(x) > 10
length(x) < 100
So the questions are as limited as they look. You can assume that in any poll I
run, the question goes only as far as it states - no hidden agenda. I restrict
the issues as much as possible because multiple issues can make the poll
indecisive, so if I wanted to add these extra ideas I would have framed them as
separate questions.
Of course, if the "of" construct were available generally, it would provide
deeper typing within the type block, which would solve part of the issues you
raise, but it would not allow naming of deeper elements.
I didn't include these suggestions of mine because I didn't think they received
enough support in the discussion thread to warrant going to a vote, although I
haven't abandoned them in my mind as ideas worth considering. I don't want the
polls to simply be a vehicle to push ideas that don't have general support. If
you think the ideas should be discussed more by all means raise a new thread. The
poll results are as limited as the questions, and the more you read the threads,
the more you wonder whether they would say something else entirely if they
happened on a different day with different personnel.
Cheers
Peter Robinson
13. Re: [POLL] Typing elements within a Type
1. No. Matt has convinced me the problems this is attempting to address would be
better done a whole new way.
2a. A1
2b. No
3. No
4a. A2
4b. No
5 b
6 a
Regards,
Pete
14. Re: [POLL] Typing elements within a Type
1 No
2a b1
2b No
3 Yes
4a b2
4b No
5 a
6 a
Yours, OtterDad
Don't sweat it -- it's not real life. It's only ones and zeroes. Gene Spafford
15. Re: [POLL] Typing elements within a Type
1. No
2.a. B1
2.b. No
3. Yes
4.a. B2
4.b. No
5. (a) and (b)
6. b
Matt
16. Re: [POLL] Typing elements within a Type
- Posted by Robert Craig <rds at RapidEu?horia?com>
Aug 31, 2007
-
Last edited Sep 01, 2007
Peter Robinson wrote:
> 1. Do you support the introduction of syntax in one of the following forms to
> allow a programmer to declare the types of elements within a user-defined type
> based on a sequence?
> [ANSWER YES OR NO]
>
> Variation A1:
>
> type customer( sequence x )
> fields
> integer x[1]
> sequence x[2]
> sequence x[3]
> end fields
> -- insert other code here
> end type
>
>
> Variation B1:
>
> type customer( sequence x )
> fields
> integer -- x[1] is assumed
> sequence -- x[2] is assumed
> sequence -- x[3] is assumed
> end fields
> -- insert other code here
> end type
NO
> 2. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? {ANSWER A1 or B1]
B1
> (b) would you support the introduction of both together?
> [ANSWER YES OR NO]
NO
> 3. Regardless of your previous answers, do you support the introduction of
> syntax
> of the same kind but with naming of elements, like this:
> [ANSWER YES or NO]
>
> Variation A2:
>
> type customer( sequence x )
> fields
> integer x[1] id
> sequence x[2] name
> sequence x[3] address
> end fields
> -- other code here
> end type
>
>
> Variation B2:
>
> type customer( sequence x )
> fields
> integer id -- x[1] is assumed
> sequence name -- x[2] is assumed
> sequence address -- x[3] is assumed
> end fields
> -- other code here
> end type
MAYBE
> 4. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? {ANSWER A2 or B2]
B2
> (b) would you support the introduction of both together?
> [ANSWER YES OR NO]
NO
> 5. Regardless of your previous answers, if syntax with naming were introduced,
> would you prefer the elements in an object declarded with this type to be
> accessible
> by:- [ANSWER a or b]
>
> (a) dot access e.g. customer_x.name; or
>
> (b) subscript/indexes e.g. customer_x[name]
NOT SURE
> 6. Regardless of your previous answers, if such syntax were introduced (with
> or without naming), would you prefer it to imply: [ANSWER a or b]
>
> (a) length(x) = 3 -- the interpreter would enforce this
>
> -- or merely
>
> (b) length(x) >= 3?
>
NOT SURE
> COMMENTS:
Adding a new run-time type to the backend for "structures",
along with integers, doubles, and sequences,
would be prohibitively expensive, as I've stated
many times before, however it might be a good thing to
allow some syntactic way to declare structure types
in the front end, with names and types of members specified,
and optional type-checking by the interpreter, as long as a
structure is just an ordinary sequence as far as the
backend is concerned.
However, I think we should probably implement the
"sequence of integer", etc. enhancement, and try it out
for a while, before we try to firmly decide on the
syntax for structure types with naming of fields, scope rules etc.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
