1. structures
Hi all,
After commenting on the type catsing, it gave me and idea.
I developed a structure sytem. It seems to work pretty well.
You can't have dynamic structures though. I think it could be worked out,
but it would make the type casting quite a bite messier though. You would
probably have to create a type for each element of the structure.
It also handles binary enumerations for flag values.
here is the code..
please let me know if you find any flaws in it.
Chris
<CODE>
sequence the_struct the_struct={}
integer enum_count enum_count=0
integer enum_mode enum_mode=1
global type structure(sequence s)
if length(s)<1 then return 0 end if
the_struct=call_func(s[1],{s[2..length(s)]})
return length(the_struct)!=0
end type
global function new_structure(integer struct_type)
if structure({struct_type}) then end if
return {struct_type}&the_struct
end function
global function enum(integer mode)
-- mode =-1 : numeric reset
-- mode =-2 : binary reset
-- mode =2 : binary enumeration
-- mode =1 : numeric enumeration
-- connot mix numeric and binary enumerations
-- mode =0 : reset to 1
-- Should NOT be used for structures..
-- Structures use the first element for internal info
-- enumerations start at two, not 1
if enum_count=0 or (enum_mode>0 and mode!=enum_mode) then mode*=-1 end if
enum_mode=mode
if mode=-1 then enum_count=2 -- numeric reset
elsif mode=-2 then enum_count=1 -- binary reset
elsif mode=2 then enum_count*=2 -- binary enumeration
else enum_count+=1 -- numeric enumeration
end if
return enum_count
end function
-- EXAMPLE STARTS HERE
function data_struct_type(sequence s)
-- this call is nesseccary to create a skeleton structure
if length(s)=0 then s={0,{0,0},0} end if
if length(s)!=3 or
not atom(s[1]) or
not sequence(s[2]) or length(s[2])!=2 or
not atom(s[2][1]) or not atom(s[2][2]) or
not atom(s[3]) then
return {} -- return an empty sequence on failure
end if
return s -- return the structure on success
end function
constant data_struct=routine_id("data_struct_type"),
-- ^ this is stored into the first element of the structure
-- structure enumerations start at '2' NOT '1'
one=enum(1),
two=enum(1),
three=enum(1)
structure data data=new_structure(data_struct)
? data
? data[one] -- element 2
? data[two] -- 3
? data[three] -- 4
while get_key()=-1 do end while
<END OF CODE>
2. Re: structures
Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> wrote:
>Oops... my last mail was sent immidiately because I see to have pressed
some
>weird short-cut key. Oh well, the same stuf.. but now finished.
I hate to waste any more bandwidth on this, so I'll merely respond to the
points you raised here that you didn't raise in the earlier post.
>I was only using the multiple-choice-question-thingie to disprove arguments
>such as 'c with sequences'. Since, in a discussion, you have a 'thing' you
>either agree with or you dont. And to support that you use *arguments*.
>After the first has used arguments, the other counters such arguments,
until
>it is impossible to do so... then you found the answer of the discussion,
>which is the goal of a discussion. (yes: .. really.. it is.. its not to
>attack any one.. or to eat your neightbourhs... its to find an
>solution/answer..)
Neither of our posts were "arguments". They were "cheap shots", designed to
make a point and stir up a strong *emotional* response. No "facts" were
"argued" at all.
>My question was meant to 'make fun' / 'confront' / 'find out' the real
>reason why people are referring to the language C in this discussion,
>althrough totally irrelevant. However, the 'C' answer I provided is for
>_those_ against structures, using real arguments: they would claim C has
got
>nothing to do with it, while you and even Robert, used C in their
arguments.
>Your 'point' above is irreleveant, because I at all times, made clear I
like
>structures on itself, without referring to other languages. (unlike you).
>Therefor, again, my question countered your argument, your question did not
>counter the point I made with my question or any other argument i used /
>point I made.
Again, please read "Problems with structures", where C is only mentioned
once, at the end:
"Introducing structures into Euphoria would *not* turn it into C."
Which seems to agree with your point.
>For your information, like I stated before ( a long time before, you might
>not have been on the list at that time), only atoms. 'Integer' is merly a
>type and a sequence itself is not data. Its a container for data. Therefor
I
>consider sequences to be a tool to arrange and manage data in the form of
>atoms. Integers are restricted atoms, no matter which way they are dealt
>with internally.
>
>However, more relevant: I did state (in the ussue of structures), that I do
>not want to add a new datatype/variable type to Euphoria. I just want an
>alternative syntax that allows me to define the *structure* of a sequence,
>and the accomodating type check function at once in an easier, better
>readable and maintainable way.
But sequences are RECURSIVE. Put a structure *inside* a generic sequence,
and how to you enforce the structure? By adding much extra overhead into the
Euphoria interpreter, which will lose speed. Plus, objects are *flexible* in
Euphoira, whereas they're not in other languages -- that's why other
languages *need* structures! Euphoria doesn't.
>Again, what does your question counter or say ? I mean.. what the hell is
>the use of it ?
A valid question for both our posts. We have succeeded in pitching the
debate on a lower level. Hooray for us.
>The point I was making, was that most (read: most (read: most)) that hate C
>and are constantly making comments about it... they never learned to
program
>in C. Those who do, have more experience, and know situations where they
>would use C rather than Euphoria. This makes such an argument like 'C with
>sequences' even weaker, since it would prove that C is not nessecarily a
>totally useless tool.
>
>Now about your question.. what is the point your making ? .. Yes I have
>experience using structures. I have two experiences using structures. The
>Original method, structures like provided in most programming languages and
>I have experience with the Euphoric method. THe thing is, it annoys me
alot:
>that Euphoric method. I have to write a complex type check function,
>declerations for a bunch of namespace eating 'constants'. (even within the
>same include) and Im allowed to use those constants inappropiately. You
know
>what I call such an experience: a bad experience.
Type checks are part of why Euphoria is so much better than all the other
languages. Variables are not restricted by *machine* types -- they can be
defined however the programmer wants to use them. This is both a benefit and
a responsibility. Instead of saying Euphoria needs structures, perhaps we
ought to approach Euphoria on its own terms, and be more careful and
selective in how and where we type-check.
As for defining constants for sequence index values, I completely agree with
you that this is annoying. I just don't think structures are the solution to
this problem.
>Now, lets get to the part of my question that you called incoherent and
>ramble at the same time is:
>(which you also cut out, and did not respond to)
Yes, I shouldn't have said that, and I apologize. I was tired and not
thinking clearly.
>Im again referring to the argument of 'structures suck because C has them
as
>well' (however much more elegantly hidden in remarks like 'C with
>sequences'). I 'unprove' this argument by saying many many more languages
>have structures, and wether or not C is a good or bad programming language,
>structures are not c-specific. Then I wondered, if you are thinking
>structures are C-specific enough for your argument to have any usefull
>contribution to this discussion.
I'm sorry, but it's you who seems to be stuck in a rut regarding C. You
*assume* that any anti-structure argument is coming from an uninformed,
unknowledgeable anti-C position. That isn't the case. Structures don't fit
into the Euphoria way of doing things. Just because other languages have
them doesn't mean they're right for Euphoria.
>I dare you to find a real counter argument, or ask you to admit C has got
>little to do with this discussion, and that its a mistake it was used as an
>argument against structures.
The only reason C has *anything* to do with this discussion is because you
keep bringing it up. My response to your questionnaire did not mention C at
all. My other detailed and example-filled posts on the subject concentrate
on *structures*, and what their introduction would *really* do to Euphoria.
C is irrelevant to the discussion. On that, we agree.
>Inverted indeed....
>Charactistics my questionaire:
> - Make a point
>Charactistics your questionnaire:
> - Dont make a point
I hope you see the point now.
Gabriel Boehme
