Re: Ideas for next Eu
On Sun, 7 Nov 1999 23:39:14 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Martin wrote:
>
>> Many of us have commented on what a pleasure
>> Euphoria is to use. For me, it lets me do whatever
>> I want with very little "expense".
>
>I agree - it's generally pleasant writing code in Euphoria, and this isn't
>something to be dismissed lightly.
>
>I personally dislike it when the compiler forces me to do things that are
>'good for me', when I know that it could certainly do things automatically.
>Variable declaration is one of them, but I've gotten used to it by now.
Which is a huge step different than the compiler just letting you get into any
trouble that you wish as Mr. Martin basically suggested. Default global is a
complete non-starter for reasons I posted about four posts back on the list by
date.
>
>Variable initialization, on the other hand, is one that still baffles me.
>Euphoria forces you to declare your variables, but you have to assign them
>on a different (logical) line of code. You can't just write:
>
> integer foo = 0
>
>but instead have to write:
>
> integer foo
> foo = 0
>
>It seems to me that if you are going to force the user to declare variables,
>and make the program abort if they are not initialized, you should let them
>intialize the variables where they are being declared.
And, it speaks to consistency. What is listed as initialization is really just
an assignment like any other.
>Shutting down the application without an error recovery routine is something
>else I take issue to. The EE editor still (very rarely) will abort on an
>error, and I'll lose data. If there was a vectored onError routine that
>could execute before program shutdown, I'd at least be able to try to save a
>backup file.
I strongly agree here...especially if Euphoria is to be used for long running,
interactive programs. But herein lies a really ugly challenge to the scoping
rules. Error routines need to be supplied by their creator with certain
inalienable rights 
These include the need to have sufficient information to
know where they were called from and sufficient scope control to both work with
the variables amongst which they were spawned and to reestablish consistency at
the point that they reenter the flow, be that at the main or at the routine from
which they were spawned. This usually requires the addition of either explicit or
implicit rules to the language.
>
>Robert seems adamant about keeping forward references difficult in Euphoria,
>because he considers this to be bad coding style. This seems to me another
>attempt to force the user into 'good coding style'. Sometimes there are
>compelling reasons to use forward references, and I don't know that making
>the user feel irritated that they have to jump through hoops is a good
>thing.
I don't think that it has anything to do with coding style or didn't until
routine_id() was shoehorned into the language. It was intrinsic to the design of
the language and the interpreter. Now that that is there, there seems little
further reason to limit forward references.
>Since I'm on a roll, I'm mention the scope constraints of routine_id and the
>fact that the value starts at zero... did I miss anything?
I'm not sure I understand exactly what you mean by scope constraints here, but I
surely understand the difficulty of controlling scope and garbage collection when
things like call_back are around.
>
>OK, moving on to the future of Euphoria. I think that the namespace is
>important. The ability to scale programs well is important, and it seems
>that Java's thought the problem through fairly well. Someone floated the
>idea of using Euphoria in HTML, similar to JavaScript - an intriguing idea.
I thought somebody was already doing CGI with Euphoria. If that can be
accomplished locally as well as on the server, then some real power will result.
After your last post to me, I researched the archives a little further, and as
confusing as that process is, gleaned a fair amount of information. In the past,
you have been a real proponent of portability. There has been a more than
sufficient discussion of namespace over a long period of time to make it crystal
clear what the need is. Modularity and interpreter control have been discussed at
a lower level, but the needs are no less clear. It seems foolish to be expanding
the platform base of the language without clearing these huge, longterm issues.
Linux and other platforms are critical longterm, but completing the language is
more important. Certainly Linux and portability should be kept in mind as the
founders code these new things. I don't think that anyone has addressed the
problem of memory fragmentation in long running programs. That is an issue that
will raise it's ugly head in long running programs if such were made possible by
error recovery.
>
>-- David Cuny
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
