Re: mainly syntax
>[END OF SLICE]
>
>Jiri wrote:
>
>> Perhaps one more syntactic niggle: I seem to be writing
>> about thousand times a day something like x = s[length(s)],
>> or s1 = s2[m..length(s2)] This could easily be replaced by,
>> say, x = s[-1], or s1 = s2[m..-1], which is more elegant and
>> saves the function call overhead as well.
Well, it would be nice, but it will make Euphoria a worse language.
The function length is needed anyway (for assignments: x= length(z))
However 'end' isn't needed, and to have two different methods of
accomplishing the exact same thing, is about the most ugly thing a language
could do.
If they had any algoritmic difference, THAN it would add something to
Euphoria, but now it's only eating away Euphoria's simplicity.
>I wrote PP under the influence of ABC, the precursor to Python, to show off
>a number of features I thought would be nice to add to Euphoria. There are
>few of them that I would now use. But the one that I wish for the most is
>Jiri's request. In PP, I offer the syntax:
That's something I am in favor off, a preproccesor version of Euphoria.
Something that is written to produce a preproccesor, that is personal to
project.
Somthing like the macro's in C, but then in a format that's more logical to
its purpose.
To keep these kind of macro's in a seperate file, you can put the techniques
you use, in this seperate commented file, so that the real program only
contains purpose stuff. (code that reads like an algoritm, instead of an
compiled Algoritm: instead of technical programming)
In this file, some1 could specify that he/she wants 'end' to be
length(sequence).
But also any form of conditional programming could be done here.
>Jacques suggests implementing this as a function. I often do that,
>reinforcing the idea that it should be native to Euphoria. The problem with
>using a function is that you can't assign, such as:
>
> bar[n..end] = "Hi there"
>
>which happens more frequently in my code that I might have thought.
bar = slice_assign(bar, n, end, "Hi there") -- end is a global constant
containing the value -1 (to make Jiri's life more livable)
See you CAN do that..!
>[Procedures ARE Functions]
>
>> And while I am raving about syntax, I cannot understand this
>> completely artificial distinction between procedures and functions.
>
>I've agree here. I'm not sure that I'd go as far as C does, with
>assignments returning values as well - but now and then, that sort of thing
>comes in handy.
It sometimes saves the overhead of copying the var's.
However, like I said, an optimizer could do that.
>Here are a couple complaints of my own:
>
>[The Tyranny of Compare]
>
>compare() vs. "=" is just trouble waiting to happen. I assume that the
>reason that Euphoria uses compare is so that the "=" operator can be
>optimized to handle numeric values. It makes me feel like I'm doing the
>work that the compiler should be doing.
if -value then
-code-
end if
Is it unlogical that -value- should be an integer ?
We are just used to BAD languages where an condition is different inside an
if-statement that when you use it with an assignment. There is no better
way.
The only thing I can image, is that a if-ing through a sequence, would
result in recursion:
if text = 'a' as index then
printf(1, "On position %i the word contains the letter
\'a\'\n",index)
end if
That would be in the syle of the ICON langauage.
>To add insult to injury, I very rarely use compare() in any other context
>than:
>
> if compare( foo, bar ) = 0 then
if not compare (foo, bar) then
reads to me as: if they don't compare then..
>which not only forces me to write a seven letter function for one of the
>most common operations, but but quite often gives me the opportunity to
>introduce the typo:
>
> if compare( foo, bar ) then
>
>which I do more often than I'd like to admit. I'd far prefer to write:
They should change to 'differ'
If they don't differ then..
And have an equal function also
if they are equal the..
if equal (foo, bar) then
if not differ (foo, bar) then
> if foo = bar then
>
>and let the compiler take care of the details. Second to that, how about:
No, it will add a whole new type of conditional syntax rules, where any
language should be consistent.
> if eq( foo, bar ) then
>
>as a native call in Euphoria, so I wouldn't incur as much overhead as a
>user-defined routine.
Yes, that's a nice idea
>I have to constantly write:
>
> foo[n+1]
Constantly ?
Then you can leave it out..
In most cases it does work better for me, there are very few and rare
situaties where I need to input or ouput an index in any way to a device or
user that likes to count from 0.
>or something similar, but they are all just errors just waiting to happen.
>With indexes referencing indexes, it's again just trouble waiting to
>happen.
?? Can you give me an example where you NEED to abstract one ?
>[On Error...Crash]
>
>When Euphoria encounters an error, it crashes. Now, I know the goal here is
>to create the most robust program possible. But there is an end user of the
>application, and how well does an immediate program shutdown serve them?
>
>Not very well, I think. They lose all their precious work - the whole point
>of using the program in the first place.
>
>At a minimum, we need a mechanism that can be called to save the user's
>precious data before the program shuts down. Preferably, I should be able
>to place a routine id in a variable:
>
> onError = routine_id( "save_user_data" )
That's a very good idea..
>Even better, I'd like some control over whether or not Euphoria decides to
>crash at all - something akin to an On Error routine in BASIC that captures
>the exceptions. Sure, it might lead to abuse - but it would be at the
>control of the programmer.
I can not image any situations where waiting for an error produces more
clear code, than preventing an error.
Ralf
|
Not Categorized, Please Help
|
|
