1. Re: New features?
From: Peter Blue
>Here are some new features I would like to see in Euphoria DOS32 :-
>3. I/O ports. Handy for writing sound card stuff
This would be good. There is ports.e, but I don't see why something
like INP and OUTP couldn't be a built-in. Well, besides maybe the fact
that EU aspires to be higher-level and hide the low-level machine details
from you. But they'd fit into machine.e well, I think.
From: Ralf Nieuwenhuijsen
>>5. Support for 3D video cards.
>What you want is to call OpenGL or DirectX.
>I (personally) would prefer DirectX since my lousy Ati card doesnt even
have
>descent OpenGL drivers..
Hmm...I don't know what drivers OpenGL requires, but I have an Ati Mach 32
card and a beta version of a game called Mordor II which uses OpenGL. It
works fine so I guess it installed the right drivers... (Something it
installed
seems to have a minor conflict with IE 4, but what doesn't?)
From: Hawke
>ive downloaded the microsloth directX SDK....YECCH!
heh Yep! Double-yecch even...
>i defnly do -not- consider the QB editor to be an integrated
>development environment...close in some ways, severely lacking tho...
I recently got a real copy of QuickBasic 4.5. I couldn't believe it,
but
the editor was actually a few steps backwards from QBasic 1.1. At
least it came with a command-line version...Eh, but I'm rambling off-topic.
From: Irv
>> 4. Event Handling like QuickBasic or PowerBasic. eg ON-TIMER, ON-KEY,
>> ON-MOUSE or even ON-SERIAL
>I was going to suggest the following constructs:
>at({10:00,2:00,4:00},DrinkDrPepper) -- set timer watchdog to call routine
>on mouse | keypress | com1 do SomeRoutine -- interrupt by input device
> activity
>when (expr) do SomeRoutine -- watch a variable for some condition, but
> -- don't abort the program, just do "SomeRoutine"
> -- which could perhaps fix the condition.
I like those three. Not full-blown event-based, but at least some built-in
event trapping to make that style of programming possible in Euphoria.
From: John DeHope
>1) Data structures
>Here is the syntax I see for #1...
> structure ClientRecord
> sequence name
> sequence address
> sequence phone_number
> atom age
> atom salary
> end sequence
> ClientRecord bob
> bob.name = "Bob Jones"
> bob.address = "1221 West Toad Street"
> bob.age = 30
Structures are a must. I just threw out my 6th try at implementing
a generic structure-handling library. <sigh> I agree with that syntax.
My latest attempt involved getting PP to turn the structure definition
above into code like:
type ClientRecord(object v )
if sequence( v ) then
if length( v ) = 5 then
if not sequence( v[1] ) then
return( FALSE )
end if
if not sequence( v[2] ) then
return( FALSE )
end if
[...] --other element type-checks
end if
end if
return( FALSE )
end type
You could then create variables of the type, and use elements
of that structure type in other structures, and otherwise use the
structure as a normal EU type. To create a untyped element in
a structure, you could just give a name without a type.
Then when the preprocessor scanned a line and found a assignment
with dot notation, it would convert that into normal variable[element]
notation and pass the element through the appropriate type-checking
function (if that element of the structure had a type defined.)
Problem was, the preprocessor would have to know what type each
structured variable was, and keep those structure definitions in
memory. If the structure or variable was defined in an include file, the
preprocessor wouldn't see it and wouldn't know what to do with the
dot-notated elements. :(
So, IMO, basic I/O port routines, basic event-trapping, and
compound/complex typed/untyped structures are the three most
necessary elements. They're some of the ugliest things to try
to program in EU now.
I think that enhanced File I/O and graphics functions, while always
welcome, would be more appropriate as add-on libraries.
Falkon
