Re: mainly syntax
[Fonts in Win32: HELP!]
Before I start fanning the flames of syntax wars, has anyone gotten font
selection in Win32 to
work? I've been trying to convert Petzold's EZ_FONT routine, but I'm not
getting anywhere.
OK, on to fan the flames... :)
[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.
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:
foo = bar[n..end]
and
foo = bar[n..end+m]
which makes the keyword 'end' do double duty, but the results are very
readable.
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.
[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.
[Dots]
Now, here's some irony. First, Jiri suggests that the ABC/Python syntax is
too radical:
if x then
for i = 1 to x do
do_something()
and suggests writing:
> if x then
> for i = 1 to x do
> do_something()..
The end result is, although they are functionally different (Python pays
attention to indentation, etc., etc.), they *look* exactly the same: only
your example seems to have added the kind of syntactic verbiage you were
trying to avoid in the first place.
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.
To add insult to injury, I very rarely use compare() in any other context
than:
if compare( foo, bar ) = 0 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:
if foo = bar then
and let the compiler take care of the details. Second to that, how about:
if eq( foo, bar ) then
as a native call in Euphoria, so I wouldn't incur as much overhead as a
user-defined routine.
[Zero Indexing]
The rest of the programming world starts counting with zero, and this is
implicit in the data structures and algorithms that those structures use.
So instead of being able to write:
foo[n]
I have to constantly write:
foo[n+1]
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.
[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" )
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.
-- David Cuny
|
Not Categorized, Please Help
|
|
