1. RE: Why UDT's aren't used.
>The only reason he SHOULD be surprised is because he hadn't been
>using the language. Anyone that has every tried to build a decent type
>check on a sequence would know that the performance hit is horrible.
>
>I as well understand why, as I assume most others do. But
>understanding has simply lead us to not using it. Using good strong
>type checking can turn a 1 second load program into a program that
>appears to simply hang for several minutes. I know, cause I've
>done it before. I've avoided type defining ever since. I don't think
>I have seen any code of Robs where he defines a type on a
>sequence in a table like manner.
>
<SNIP>
>-----------------------
>PhoneBook PB
>
>PB = {}
></eucode>
{{{
>
>Now who wants to write code to actually items to the phone book?
>Better yet, Who would dare to use this with type checking enabled?
Certainly not me... I hate to think how much overhead is involved,
especially if something horrific is done like import this phone book from a
file... <shudders>
I wish something could be done about structuring types. The hardest part of
your type code (and same for any structured type) is the PhoneBook item....
It would be nice if there was a way to reference elements of a structured
type by name. The only way to do this at the moment is to define constants,
and use var[ELEM_NAME]. There are problems with type-checking on large
structured types, because like with arrays at the moment, we have to check
every sequence every time something changes.
Something that would be nice:
type phoneBookItem( structured sequence x)
...some form of special declaration giving name and type of each
element to be in x...
end type
The two main problems with this:
1. Assigning a literal to a structured sequence will be very tricky.
2. It's likely to be too radical for Rob to approve.
MrTrick
2. RE: Why UDT's aren't used.
On 4 Jun 2004, at 10:13, Patrick Barnes wrote:
>
>
> >The only reason he SHOULD be surprised is because he hadn't been
> >using the language. Anyone that has every tried to build a decent type
> >check on a sequence would know that the performance hit is horrible.
> >
> >I as well understand why, as I assume most others do. But
> >understanding has simply lead us to not using it. Using good strong
> >type checking can turn a 1 second load program into a program that
> >appears to simply hang for several minutes. I know, cause I've
> >done it before. I've avoided type defining ever since. I don't think
> >I have seen any code of Robs where he defines a type on a
> >sequence in a table like manner.
> >
> <SNIP>
> >-----------------------
> >PhoneBook PB
> >
> >PB = {}
> ></eucode>
{{{
> >
> >Now who wants to write code to actually items to the phone book?
> >Better yet, Who would dare to use this with type checking enabled?
>
> Certainly not me... I hate to think how much overhead is involved,
> especially if something horrific is done like import this phone book from a
> file... <shudders>
>
> I wish something could be done about structuring types. The hardest part of
> your
> type code (and same for any structured type) is the PhoneBook item.... It
> would
> be nice if there was a way to reference elements of a structured type by name.
> The only way to do this at the moment is to define constants, and use
> var[ELEM_NAME]. There are problems with type-checking on large structured
> types,
> because like with arrays at the moment, we have to check every sequence every
> time something changes.
>
> Something that would be nice:
> type phoneBookItem( structured sequence x)
> ...some form of special declaration giving name and type of each
> element to be in x...
> end type
>
> The two main problems with this:
> 1. Assigning a literal to a structured sequence will be very tricky.
> 2. It's likely to be too radical for Rob to approve.
Thinking radically.......
add the var as a dynamic include pointer. Or a string execution item.
Fetching from it or saving to it is a function call. It runs code only on
itself, it
returns things such as it's value or error code. It could call other code that
you can write to perform actions when some var is changed. As for returning
*native* types, point to predefined types in shared memory.
But then, RobC sees no use for string execution or for dynamic includes.
Drat it. Vote time again?
Kat
3. RE: Why UDT's aren't used.
>From: Kat <gertie at visionsix.com>
> > >Now who wants to write code to actually items to the phone book?
> > >Better yet, Who would dare to use this with type checking enabled?
> >
> > Certainly not me... I hate to think how much overhead is involved,
> > especially if something horrific is done like import this phone book
>from a
> > file... <shudders>
> >
> > I wish something could be done about structuring types. The hardest part
>of your
> > type code (and same for any structured type) is the PhoneBook item....
>It would
> > be nice if there was a way to reference elements of a structured type by
>name.
> > The only way to do this at the moment is to define constants, and use
> > var[ELEM_NAME]. There are problems with type-checking on large
>structured types,
> > because like with arrays at the moment, we have to check every sequence
>every
> > time something changes.
> >
> > Something that would be nice:
> > type phoneBookItem( structured sequence x)
> > ...some form of special declaration giving name and type of each
> > element to be in x...
> > end type
> >
> > The two main problems with this:
> > 1. Assigning a literal to a structured sequence will be very tricky.
> > 2. It's likely to be too radical for Rob to approve.
>
>Thinking radically.......
>
>add the var as a dynamic include pointer. Or a string execution item.
>Fetching from it or saving to it is a function call. It runs code only on
>itself, it
>returns things such as it's value or error code. It could call other code
>that
>you can write to perform actions when some var is changed. As for returning
>*native* types, point to predefined types in shared memory.
>
>But then, RobC sees no use for string execution or for dynamic includes.
>Drat it. Vote time again?
>Kat
<blink> <blink>
Um... I'm sorry, I have no idea what you are talking about.
Never mind implementation for now.... What we would LIKE in a structured
type:
*Ability to refer to a member of the type by name
*Ability to only need to type check variables that have changed
*Not losing the ability to easily cast between generic sequences and
structured types.
*Not losing the ability to easily cast between structured types and generic
sequences.
*Not losing the ability to assign literals to the variable to create a new
instance of that type.
*Ability to use these structured types inside arrays (and use the "of"
mechanism to make it efficient :o) )
*Ability to add new members to the structured type without breaking existing
code (or providing *very* easily followed error messages in places that this
is not possible, like assigning a literal to the entire sequence.
I think that's about it for now. :o)
MrTrick
4. RE: Why UDT's aren't used.
On 4 Jun 2004, at 12:19, Patrick Barnes wrote:
>
>
> >From: Kat <gertie at visionsix.com>
> > > >Now who wants to write code to actually items to the phone book?
> > > >Better yet, Who would dare to use this with type checking enabled?
> > >
> > > Certainly not me... I hate to think how much overhead is involved,
> > > especially if something horrific is done like import this phone book
> >from a
> > > file... <shudders>
> > >
> > > I wish something could be done about structuring types. The hardest part
> >of your
> > > type code (and same for any structured type) is the PhoneBook item....
> >It would
> > > be nice if there was a way to reference elements of a structured type by
> >name.
> > > The only way to do this at the moment is to define constants, and use
> > > var[ELEM_NAME]. There are problems with type-checking on large
> >structured types,
> > > because like with arrays at the moment, we have to check every sequence
> >every
> > > time something changes.
> > >
> > > Something that would be nice:
> > > type phoneBookItem( structured sequence x)
> > > ...some form of special declaration giving name and type of each
> > > element to be in x...
> > > end type
> > >
> > > The two main problems with this:
> > > 1. Assigning a literal to a structured sequence will be very tricky.
> > > 2. It's likely to be too radical for Rob to approve.
> >
> >Thinking radically.......
> >
> >add the var as a dynamic include pointer. Or a string execution item.
> >Fetching from it or saving to it is a function call. It runs code only on
> >itself, it returns things such as it's value or error code. It could call
> >other
> >code that you can write to perform actions when some var is changed. As for
> >returning *native* types, point to predefined types in shared memory.
> >
> >But then, RobC sees no use for string execution or for dynamic includes.
> >Drat it. Vote time again?
> >Kat
>
> <blink> <blink>
> Um... I'm sorry, I have no idea what you are talking about.
It didn't look like Latin when i sent it, i swear.
Ok,,,
Lets say you have a include, it has code to write out another include (i am
figuring RobC will bite at dynamic includes before string execution) which
takes your structure parameters (read from a template file you provided with
that data in it), along with any operations you wish to perform on each var
(read from same template file), so when you "build" a structured var, the
template is effectively duplicated for that var. The template can have code to
call a global checking/fixing/aborting function you have written, and the
template supplies the name/contents/type of the var, and you munge it,
returning a ok/nogo/altered contents. Every time Eu accesses that var, it's a
function call, and the template used to build that var structure returns the
value in that structure:
puts(1,my_struct(FETCH,userinput[1],NAME,AGE)&"\n")
my_struct accepts that sequence/integer/mouse/whatever[1] , and the values
of whatever NAME and AGE are, and returns some values. On the other
paw, if you were assigning to my_struct(), and AGE was listed as 'z', it
wouldn't matter if Eu passed it as a atom/integer, because no one is 122
years old, and your code in the template would verify those limits,, AND NOT
VERIFY ANY OTHER VAR'S AGES.
> Never mind implementation for now.... What we would LIKE in a structured
> type:
> *Ability to refer to a member of the type by name
Answered above.
> *Ability to only need to type check variables that have changed
Answered above.
> *Not losing the ability to easily cast between generic sequences and
> structured types.
Answered above.
> *Not losing the ability to easily cast between structured types and generic
> sequences. *Not losing the ability to assign literals to the variable to
> create
> a new instance of that type. *Ability to use these structured types inside
> arrays (and use the "of" mechanism to make it efficient :o) ) *Ability to
> add
> new members to the structured type without breaking existing code (or
> providing
> *very* easily followed error messages in places that this is not possible,
> like
> assigning a literal to the entire sequence.
Answered above. (didn't i?)
The same applies to executing strings, it's only diff is how Eu would handle a
dynamic include vs a exec(string). Obviously, there'd be a difference in
syntax as you'd code the access to the vars.
Kat
5. RE: Why UDT's aren't used.
>From: Kat <gertie at visionsix.com>
>Subject: RE: Why UDT's aren't used.
> > <blink> <blink>
> > Um... I'm sorry, I have no idea what you are talking about.
>
>It didn't look like Latin when i sent it, i swear.
>
>Ok,,,
<SNIP>
>Answered above. (didn't i?)
Well, not really. There are problems I can see with that implementation:
*Structures have to be declared in their own file.
*Assigning structures to sequences and vice-versa is non-transparent
*You can't just go myStruct.name = "Jiminy" like other languages (and that's
what users expect)
*dynamic includes and separate issues they create just for a dinky little
structure functionality
*Need to write files just to use a structure.
*How do you do arrays of structures? Transparently - no function overhead?
Kat, I think your approach may work properly, but it is very difficult to
make sense of, and it differs majorly from how people expect.
>The same applies to executing strings, it's only diff is how Eu would
>handle a
>dynamic include vs a exec(string). Obviously, there'd be a difference in
>syntax as you'd code the access to the vars.
Executing strings is a completely different issue. I think we should keep as
many things de-coupled as possible ('of', strings, structures, threads,
string execution, etc)
MrTrick
