1. Rob: Q: Euphoria 2.6
Now that Euphoria 2.5 is out, what new features can we look foward to
in Euphoria 2.6? Or perhaps you are planning on skipping all the way to
3.0?
2. Re: Rob: Q: Euphoria 2.6
I'd like to see some structure support for Euphoria since when dealing with
the Windows API we need to use structures. Also I would like to see the '^'
(carrot symbol) used to define pointers...
eg:.. }}}
<eucode>
integer Value
?^Value -- displays the address of "Value" rather than the value.
-- make scence?
-- on the note of structure support one idea to do this would be some thing
-- like this... (builtin like "constant")
structre Array={integer el_one, integer el_two, atom el_three, sequence
ptr_four}
-- obviously there is no easy way to support the "object" definition
-- but this way would support user types.
?^Array -- would display an address (pointer) to the structure
?^Array[3] -- would display an address (pointer) to the 3rd element
?^Array[4] -- pointer to the union/structure at element four.
?Array -- treated like a normal sequence
-- another example useing pete's asm...
include asm2.e
integer
value
value = 1
atom
asm_code
asm_code = get_asm(
"mav eax [^value] " &
"etc...")
-- no more need for a "resolve_param()"
</eucode>
{{{
I'd like hear some peoples ides on structure/pointer support and weather it
would be suitable for Euphoria.
3. Re: Rob: Q: Euphoria 2.6
Hayden McKay wrote:
>
> I'd like to see some structure support for Euphoria since when dealing with
> the Windows API we need to use structures. Also I would like to see the '^'
> (carrot symbol) used to define pointers...
>
<snip>
Hayden, if you want C, then why not just use C?
Regards, John
4. Re: Rob: Q: Euphoria 2.6
Vincent wrote:
> Now that Euphoria 2.5 is out, what new features can we look foward to
> in Euphoria 2.6? Or perhaps you are planning on skipping all the way to
> 3.0?
I have a long list of minor issues to look at,
but I'm still open to suggestions for some major features.
I may look into threads in more detail.
Hayden McKay wrote:
> I'd like to see some structure support for Euphoria since when dealing with
> the Windows API we need to use structures. Also I would like to see the '^'
> (carrot symbol) used to define pointers...
>
> eg:..
>
> integer Value
> ? ^Value -- displays the address of "Value" rather than the value.
I'm opposed to C-style pointers and structures.
Programming in a world of values, is fundamentally cleaner
than programming in a world of storage "locations" that hold values,
where the values occupy a certain number of bytes in a certain format.
I would never want to give you the address of a Euphoria variable.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Rob: Q: Euphoria 2.6
- Posted by Jason Gade <jaygade at yahoo.com>
Mar 29, 2005
-
Last edited Mar 30, 2005
Robert Craig wrote:
>
> Vincent wrote:
> > Now that Euphoria 2.5 is out, what new features can we look foward to
> > in Euphoria 2.6? Or perhaps you are planning on skipping all the way to
> > 3.0?
>
> I have a long list of minor issues to look at,
> but I'm still open to suggestions for some major features.
> I may look into threads in more detail.
>
> Hayden McKay wrote:
> > I'd like to see some structure support for Euphoria since when dealing with
> > the Windows API we need to use structures. Also I would like to see the '^'
> > (carrot symbol) used to define pointers...
> >
> > eg:..
> >
> > integer Value
> > ? ^Value -- displays the address of "Value" rather than the value.
>
> I'm opposed to C-style pointers and structures.
> Programming in a world of values, is fundamentally cleaner
> than programming in a world of storage "locations" that hold values,
> where the values occupy a certain number of bytes in a certain format.
> I would never want to give you the address of a Euphoria variable.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Here we go again, haha!
Better modularity would be nice. I wouldn't care if it was via an 'import'
keyword or fixing the so-called include bug. Keeping data and functions in a
module and importing them with a namespace can be very object-oriented-like.
Allow routine id's to be forward referenced. I've searched the archive for the
arguments against this and I couldn't find them. All I could find was a note
from Rob saying it was controversial. Routine id's already get around the normal
function calling process. Being able to forward reference would be a boon to
writers of large libraries (win32lib).
Those two are the biggest.
I think that people tinkering with the source code and coming with with variable
id's is pretty cool as well. It is orthogonal with the routine id method.
Being able to modify by reference explicitly, either by variable id or by
in/out/inout declarations. Or by optimizing the case where foo=somefunc(foo)
=====================================
Too many freaks, not enough circuses.
j.
6. Re: Rob: Q: Euphoria 2.6
- Posted by cklester <cklester at yahoo.com>
Mar 29, 2005
-
Last edited Mar 30, 2005
Jason Gade wrote:
>
> Better modularity would be nice. I wouldn't care if it was via an 'import'
> keyword
> or fixing the so-called include bug.
I almost sent in a comment about this the other day. I think an 'import'
directive/command/keyword would simply bring the code referenced into the
current namespace.
import a.e
function k()
import k.e
end function
etc...
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
7. Re: Rob: Q: Euphoria 2.6
- Posted by h4x3r <h4x3r at bellsouth.net>
Mar 29, 2005
-
Last edited Mar 30, 2005
On Tue, 2005-03-29 at 10:23 -0800, Robert Craig wrote:
> I have a long list of minor issues to look at,
> but I'm still open to suggestions for some major features.
> I may look into threads in more detail.
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Threads are they really safe and DREINTRANT maybe...
This would be the greatest thing since sliced cheese though.
Im all for threads..
8. Re: Rob: Q: Euphoria 2.6
Hayden,
May be you should code in C. The idea behind a high level language like
euphoria
is to avoid any pointers and memory management trouble. In my opinion memory
allocation and structure should be only used to interface to the windows API
and hidden inside the wrappers library like win32lib and others do.
regard,
Jacques d.
9. Re: Rob: Q: Euphoria 2.6
I vote for Threads too.
jacques d.
10. Re: Rob: Q: Euphoria 2.6
Yes one could just use C but my comment was only a suggestion.
I just wanted to see what other uses thought of the carrot ('^') idea
since it would eliminate calls to allocate poke etc.. in some cases
I like the feedback.... without it Euphoria would lack user direction
11. Re: Rob: Q: Euphoria 2.6
jacques deschênes wrote:
>
>
> I vote for Threads too.
>
> jacques d.
>
Me too!
12. Re: Rob: Q: Euphoria 2.6
I vote for threads as well. However, what about DOS? Unless you really want to
attempt to write your own cooperative multitasking system yourself then threads
on DOs would be impossible. Some may say that DOS is obsolete and no one uses it
but I use it both at home and at work in pure DOS environments (FreeDOS usually).
I also would LOVE variable referencing via variable_id(), read_var(), and
write_var() style commands. Heck, even make a pointer data type if you want but
if I could add anything to Euphoria I would add this over threads or an "include
bug" fix. Many a headache has been due to trying to access and modify data fields
in an "object" when trying to do OOP stuff and it would be solved almost
instantly by adding these commands.
Also, I think that some form of a version() routine is absolutely essential.
13. Re: Rob: Q: Euphoria 2.6
hi,
i vote for threads too.
maybe one could get them with a soon to be expected?? interim update??
richard
14. Re: Rob: Q: Euphoria 2.6
richard koch wrote:
>
> hi,
>
> i vote for threads too.
> maybe one could get them with a soon to be expected?? interim update??
>
> richard
>
If Rob were to implement multi-threading capabilities with Euphoria...
I would assume there would need to be significant modifications to the
source code, thus I would suspect it would take quite some time to get
a stable system working.
I wouldn't be suprized if it took upto 1.5/2 years for the next alpha
release, if such a feature like threads were to be supported.
I think many of us would wait patiently, wouldn't we?
Absolutely! 
Regards,
Vincent
Euphoria v2.5 Rocks!!!
15. Re: Rob: Q: Euphoria 2.6
On 29 Mar 2005, at 21:55, Hayden McKay wrote:
>
>
> posted by: Hayden McKay <hmck1 at dodo.com.au>
>
> Yes one could just use C but my comment was only a suggestion.
> I just wanted to see what other uses thought of the carrot ('^') idea
> since it would eliminate calls to allocate poke etc.. in some cases
I asked for pointers years ago. They have their uses. Those routine_id() are
just disguised pointers. I also asked for goto.
> I like the feedback.... without it Euphoria would lack user direction
It still lacks user direction.
Kat
16. Re: Rob: Q: Euphoria 2.6
jacques deschênes wrote:
>
>
> Hayden,
> May be you should code in C. The idea behind a high level language like
> euphoria
> is to avoid any pointers and memory management trouble. In my opinion memory
> allocation and structure should be only used to interface to the windows API
> and hidden inside the wrappers library like win32lib and others do.
>
> regard,
> Jacques d.
>
From a theoretical standpoint, I agree.
For this approach to be practical, there should be wrappers for _every_
low level OS dependant stuff an Euphoria programmer may have to deal with.
Sorry, that's not the case as of today, and probably never will.
The OpenEu specs call for a full set of raw memory management commands. They
don't create Euphoria objects, just placeholders for various known memory
storage types
like strings, counted strings and a lot more; the only interface between
these raw mem objects and the language is assignment both ways.
These primitives are intended only for interfacing with the host machine,
and most serious programming has to deal, in a limited way, with that.
Eu has quite a few instructions to implement pointers or deal with pointers.
The only thing I happened to need would be an allocate_at(location,size) new
primitive so as to handle and manage raw memory blocks better.
If you don't have pointers, then some kind of variable_id(), get_var(id) and
set_var(id,value)
is needed. Thus, you get the flexibility of C and the safety net of Eu.
But having neither these nor pointers is a real issue in Eu.
CChris
