1. RE: Digest for EUforum at topica.com, issue 5758
> Subject: Re: Rob: List?
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> CChris wrote:
> > > 2. provide non-blocking I/O support to assist multitasking
> > >
> >
> > Could you elaborate on this? If it means that Eu gets at
> last a set of file
> >
> > xplat commands which are not blocking, this is a welcome
> development.
> > How would a progress or completion status for a I/O command
> be reported?
>
> I haven't decided exactly how it will work, but Linux and Windows
> have API calls that let you start some I/O, and then check a variable
> or memory location to detect when it has finished. Meanwhile you can
> do other things, rather than getting blocked at that point.
>
Of course, and the current mechanisms in Eu already allow to wrap and use
them. So what is this support made of? That was my original question.
> > > 3. Incorporate Daniel's multi-threaded non-blocking WIN32
> API calls
> > >
> >
> > Seems to overlap 2) above.
>
> > Also, isn't it simpler to extend the semantics of
> > "integer" to cover what ALL language around do, ie machine
> size integers
> > (32 or 64 bit according to host hardware)?
>
> I have no idea what integers have to do with non-blocking API calls,
> but Euphoria's integers only use 31 bits, because (effectively)
> there is a bit that says "this is not an integer, it's
> a pointer to a larger object". Most other languages don't have
> dynamic "larger objects" like Euphoria's sequences.
>
Sorry, was mixing this issue with another odll (thought he wrote it too)
which alows to use 32-bit integers when talking with dll/apps made with sany
other language.
Most other languages have dynamic objects like sequences with various names,
all those that are object aware at least. (note: I hardly ever used Basic) I
admit that joining sequences is easier in Eu than in these other languages,
but that's only one strong point versus many others.
I use "object aware" for languages that are hybrid like C++ or Delphi, as
opposed to "object oriented" ones like Java or Eiffel.
> > And why do this in Windows only
> > then? Looks like a half baked thing.
>
> If it turns out to be easy, why not?
>
> > > 6. front-end optimization of temps - fewer temps gives
> better performance
> > >
> > > 7. try again to speed up scanning/parsing/emiting (front end)
>
> > Are you sure the time you'll spend in these tricky
> optimisations will not
> > outweigh the sum of all execution time gains achieved through them?
> > Perhaps most Eu users still use 486s or older, in which
> case these are relevant.
> >
> > If not, see my final comments.
> >
> > > 8. Translator optimizations:
> > > - translator: if a call_proc/call_func has an
> argument sequence where
> > > all the elements are known to be integers, we
> shouldn't bother to
> > > emit Ref's on the elements
> > >
> > > - could easily optimize code generation for
> compare() in translator
> > >
> >
> > Ok, these are probably useful. When I *really* (and rarely)
> need raw speed,
> >
> > I directly code in C if asm is not an option. Here again,
> are these little
> > optimisations worth your efforts?
>
> When you optimize code you always run into diminishing returns.
> You start off making some impressive improvements in speed with
> very little effort. Eventually you start expending a lot of coding
> effort just to shave 1% off the time. It's a judgement call
> that I will have to make.
>
Absolutely. And there is so much more to do so as to make the language
easier to use, I mean, with less workarounds.
> > Development and testing time is much larger than execution time,
> > except for very specific tasks. Hence I would have welcome
> anything that makes
> > Euphoria more flexible when it comes to coding, since bugs
> usually arise in
> >
> > the translation from the developer's goals and the
> constrained extent of what
> >
> > an interpreter can understand.
> >
> > But nothing in the above suggests any move towards this direction:
> >
> > - No provision for having a better control on what is, or
> is not, in namespaces,
> > and specially in the unnamed one where all global symbol live;
>
> I don't want to open the namespace issue.
> I suspect most people don't use it, and don't fully understand it,
> let alone wish to see it become more complicated.
>
But why shutting the door on those that would be able to use it effectively?
> > - No provision to allow passing arguments as reference to routines;
>
> I have no desire to do that.
> Euphoria should be based on values, not locations that can be
> pointed-to and changed in subtle indirect ways.
>
And then you wind up coding:
function xyz(sequence all_the_data_the routine processes)
--...
end function
--...
modified_vars=xyz({var1,var2...var6})
var1=modified_vars[1]
--...
var6=modified_vars[6]
Is this any more elegant? any more efficient? any more bug preventive?
Oh I forgot, you can use global variables to avoid this, and you must do so
anyway if xyz() is in some utility include file. See the "namespace" earlier
point.
> > - No provision to allow more practical, yet structured,
> control over execution
> > flow,
> > which could take the form of:
> > * optional argument to the exit statement: exit n
> loops/exit the loop with this
> > label
> > * a continue statement (skip remainder of current iteration)
> > * a retry statement (restart current iteration)
> > * a select (or switch, or inspect...) statement to handle
> multiple choices
>
> There's nothing really wrong with adding a bunch of new control-flow
> statements. It's simply my philosophy that Euphoria should have a
> small number of control-flow statements. That might bother some
> professional programmers in some instances, but will ease the
> burden on beginners and hobbyists.
>
Why not make the additions and then organise the doc in two tiers: one with
the few statements which you deem understandable by most users, and the
other tier for more advanced users? This would keep your philosophy intact
while making the language easier to use.
> > Also, I really think some integrated tool to manage context
> switch in
> > multitasked environments is needed, because the same
> library may be queried
> >
> > by different tasks "at the same time", ie while some not
> shareable data is
> > being used. Most OSes know about thread vars, this could be
> the simplest way
> >
> > to go. Except DOS admittedly.
>
> When more people start using multitasking, we'll have
> a much better idea of what additional features are needed.
>
> Note that I probably won't implement all of these features.
> I could back out of something if it looks harder or
> less useful than I thought at first. Also, I'm sure
> I'll end up doing some other things that aren't on this list.
>
By the way, you had mentioned a possibility of adding exception handling to
Eu. That could have been useful, but disappeared from your list. Are you
still considering this move?
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
At least there is some clear directions stated as to where the language is
heading and where it won't head. I must admit than I am not too happy with a
sizable portion of these directions.
CChris
2. RE: Digest for EUforum at topica.com, issue 5758
To me it's not realy a big deal. If you want optimized code asm would be my
first preference. I find Eu handy for testing out alogs and fun to use when
ur learning something new or for just plain playing arround. It's easy code
to work with and you can create something that works without worrying about
all the fickle things in other languages.
There are many languages to suit specific needs. If one language does'nt do
the job for a perticular project or task it's probably best to use one that
that doe's.
Keep Euphoria simple...easier than basic.
3. RE: Digest for EUforum at topica.com, issue 5758
Cuvier Christian wrote:
>
> >
> > > Also, isn't it simpler to extend the semantics of
> > > "integer" to cover what ALL language around do, ie machine
> > > size integers (32 or 64 bit according to host hardware)?
> >
> > I have no idea what integers have to do with non-blocking API calls,
> > but Euphoria's integers only use 31 bits, because (effectively)
> > there is a bit that says "this is not an integer, it's
> > a pointer to a larger object". Most other languages don't have
> > dynamic "larger objects" like Euphoria's sequences.
> >
>
> Sorry, was mixing this issue with another odll (thought he wrote it too)
> which alows to use 32-bit integers when talking with dll/apps made with sany
> other language.
>
No, this was something I'd done. It doesn't require a dll, but just some
added euphoria code and a little preprocessing of the translated c files
before compiling.
> Most other languages have dynamic objects like sequences with various names,
> all those that are object aware at least. (note: I hardly ever used Basic) I
> admit that joining sequences is easier in Eu than in these other languages,
> but that's only one strong point versus many others.
> I use "object aware" for languages that are hybrid like C++ or Delphi, as
> opposed to "object oriented" ones like Java or Eiffel.
>
As someone who's but a bit of thought into this subject, I think you'll
find that there's not likely a faster way to implement Euphoria's datatypes.
Rob's found a solution that allows him to quickly determine a value's type
with a minimum of overhead. Any 'object aware' language will likey either
add lots of overhead (i.e., slow) or be very strictly and statically typed
(and kill a lot of what makes Euphoria worthwhile).
That said, if you can come up with another solution that can balance these
issues (speed vs overhead) I'd be interested to hear it. Of course, once
Euphoria goes 64 bits, we could probably make the case for other new
datatypes.
Matt Lewis
