1. mainly syntax
Cameron Kaiser wrote:
>I tried Python, but I'm not a fan of object oriented languages and at least
>Perl lets you not be OOP if you want to. (Although to my displeasure it's
>leaning OOP heavily these days. Gimme Perl 4 back!) But I did like the
>syntax; very lucid 
It depends what you want to do, for some tasks OOP is very handy. For
example design of GUIs. For a number of weeks now I have been trying
to come up with a relatively simple GUI framework and I am finding it
very, very difficult without resorting to some form of OO. The trouble
is, because Euphoria does not allow parameter parsing by reference
(what a pity!), I have to set up a number of external structures to
hold even transient values, and the whole thing becomes very messy.
Cameron also mentioned syntax. I think it is quite important, because
computer languages are a bit like religions, and syntax matters a lot
especially in the early stages of conversion. I like Euphoria's
syntax, but I must admit I am getting tired of some aspects of it,
e.g. endlessly typing 'end procedure', 'end if', 'end while', etc. It
is just as useful as 'begin... end' brackets, or the semicolon in
pascal... I am not advocating Python's use of indentation, it is too
controversial, but what about replacing the whole lot of these
crutches with a simple "." (dot). So instead of, say,
if x then
for i=1 to x do
do_something()
end for
end if
we would have
if x then
for i=1 to x do
do_something() ..
Neat,eh?! The first dot for 'end for', and the second one for 'end if'.
And the compiler/interpreter can tell us anyway, if and why the dots
do not match.
And while I am raving about syntax, I cannot understand this
completely artificial distinction between procedures and functions.
After all, functions are merely routines that return a value while
procedures do not. So why a different mechanism? The so called
'safety' argument is even weaker here than for the crutches above.
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 better stop here, otherwise Ralf will justly start complaining about
the amount of space I usurp on this server. Jiri
2. Re: mainly syntax
Babor 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],
>
i just realized that i also have wanted this from the beginning of my
Euphoria programming...
Bye -- from Lee woo seob.
3. Re: mainly syntax
I disagree with everyting (!!!) that BABOR, JIRI jsut wrote:
> we would have
>
> if x then
> for i=1 to x do
> do_something() ..
> Neat,eh?! The first dot for 'end for', and the second one for 'end if'.
> And the compiler/interpreter can tell us anyway, if and why the dots
> do not match.
Yuck, shades of LISP and its onion peels )))))))))) !
My eyes water peeling those parentheses. Not only mine:
later implementations allowed ] as a shorthand for any
number of )))))))
> And while I am raving about syntax, I cannot understand this
> completely artificial distinction between procedures and functions.
> After all, functions are merely routines that return a value while
> procedures do not. So why a different mechanism? The so called
> 'safety' argument is even weaker here than for the crutches above.
I was surprised too, and I did say it here, because it broke all my
ingrained habits. However, I remembered an article from way back in
which some big shot in computer science was arguing that a procedure
should be allowed only two parameters: input, passed by value (i.e.
read-only) and output. Euphoria implements it partly in its own way,
and I have no bones about it.
> 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)]
Me, only dozens.
> 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.
That is strange, not syntax, but semantics. This use of -1 is an
exception
worthy of C's "->" which really stands for "*.", is not easier to type,
and adds one more thing to remember which could be dispensed with very
nicely. Rather than seeing it implemented in the language, I'd rather
see programmers who want it implement it themselves, like this for
instance:
function sub(sequence s, atom start, atom stop)
if stop=-1 then stop=length(s)
end if
return s[start..stop]
end function
4. 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
5. Re: mainly syntax
Hi,
One more thing on the syntax...
i hope i could use ^ or ** operator instead of using the power() function
in the future version of Euphoria...
Bye - from Lee, woo seob
6. Re: mainly syntax
Jacques Guy just wrote:
>I disagree with everyting (!!!) that BABOR, JIRI jsut wrote:
..
>Yuck, shades of LISP and its onion peels )))))))))) !
>My eyes water peeling those parentheses. Not only mine:
>later implementations allowed ] as a shorthand for any
>number of )))))))
Very unfair comparison, but I am a lousy, slow typist and would prefer
to count up to half dozen dots to scrolling through and extra page of
wasted space to get my bearings...
>I was surprised too, and I did say it here, because it broke all my
>ingrained habits. However, I remembered an article from way back in
>which some big shot in computer science was arguing that a procedure
>should be allowed only two parameters: input, passed by value (i.e.
>read-only) and output. Euphoria implements it partly in its own way,
>and I have no bones about it.
Enlighten us! Did she/he have a valid argument or was it just the big
shot's name that impressed you so much?
>> 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)]
>
>Me, only dozens.
>
>> 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.
>
>That is strange, not syntax, but semantics. This use of -1 is an
>exception
>worthy of C's "->" which really stands for "*.", is not easier to type,
>and adds one more thing to remember which could be dispensed with very
>nicely. <snip>
Ok, if speed does not matter to you, or if you have a memory problem,
go on, use length(); -1 value would wake *me* up! Jiri
7. Re: mainly syntax
I agree with just about everything David Cunny just wrote!
[END OF SLICE]
> foo = bar[n..end]
is possibly more readable than foo = bar[n..-1], but -1 is somehow
more appealing to my warped mind. (I must have a look at your PP
again, David!)
Btw, what are the origins of this "foo" thing in computing? Am I
missing something here, because English is not my first language?
[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.
Not so much irony, just a bit of an old fashioned compromise. I want
the brevity, but do not wish to impose any layout restrictions.
Basically, I want to keep the indentation style for my own purposes...
[The Tyranny of Compare]
Again, I agree, it should be compiler's job to sort out all possible
meanings of "=".
[Zero Indexing]
If you are a non-Mayan, it is perhaps initially a bit more natural to start
counting from one, but it becomes quite tedious quite quickly to be
force to add and subtract ones all the time. At least, the language
should give you a choice. Jiri
8. Re: mainly syntax
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM>
Feb 17, 1998
-
Last edited Feb 18, 1998
Hello everyone,
[FOOBAR]
Well, I can't be sure where or when this originated, but I know it started
out with the acronym FUBAR. This stands for "fouled up beyond all
recognition" (or f**ked up, depending on your level of vulgarity). It was
quickly applied to computer programming, and in the quest for creative
variable naming conventions, "foo" and "bar" started showing up for
arbitrary variable names and programming examples. Yeah.
[END OF SLICE]
It would be nice not to have to retype the name of a sequence just to get
a slice up to the end. mysequence = mysequence[2..length(mysequence)]
[APPEND]
Same type of problem here. mysequence = append(mysequence, newthing) gets
a little tedious. I like the suggestion for mysequence.append(newthing)
because it's closer to OOP and connecting methods to data.
[The tyranny of compare?]
What's wrong with compare? Compare is neccessary because using =,<,> on a
sequence compares each element of a sequence individually with each
element in another sequence. This works great for a replacement algorithm
in this line of code: s = s + ('X'-'x')*(s = 'x') -- this makes all
occurrences of 'x' into 'X'
[OOP]
I would like to use the discipline of OOP with Euphoria. It could be
possible with a preprocessor, I think. Virtual procedures and functions
would be fairly easy to implement now that we have routine_id and
call_proc.
Later,
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
9. Re: mainly syntax
>Cameron Kaiser wrote:
>
>>I tried Python, but I'm not a fan of object oriented languages and at
least
>>Perl lets you not be OOP if you want to. (Although to my displeasure it's
>>leaning OOP heavily these days. Gimme Perl 4 back!) But I did like the
>>syntax; very lucid
>
>Cameron also mentioned syntax. I think it is quite important, because
>computer languages are a bit like religions, and syntax matters a lot
>especially in the early stages of conversion. I like Euphoria's
>syntax, but I must admit I am getting tired of some aspects of it,
>e.g. endlessly typing 'end procedure', 'end if', 'end while', etc. It
>is just as useful as 'begin... end' brackets, or the semicolon in
>pascal... I am not advocating Python's use of indentation, it is too
>controversial, but what about replacing the whole lot of these
>crutches with a simple "." (dot). So instead of, say,
A dot more or less looks ok, but easily creates an error, there is btw
no endless typing with the syntax completition, as the standard editor does.
>And while I am raving about syntax, I cannot understand this
>completely artificial distinction between procedures and functions.
>After all, functions are merely routines that return a value while
>procedures do not. So why a different mechanism? The so called
>'safety' argument is even weaker here than for the crutches above.
What do you mean by this ?
That statements, like in C, should return a value also.
That would be more efficient and in some cases more clear, however is
most cases it makes the code less readable and the efficiency could also be
made up by a smart optimizer.
>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.
-1 is more elegant ?
'end' might be more elegant, but a number as -1 isn't
The overhead btw, is almost zero, it's a built-in function.. and it has
to lookup the length anyway, because the length may vary during run-time.
>I better stop here, otherwise Ralf will justly start complaining about
>the amount of space I usurp on this server. Jiri
Why ?
Not again!
Do you have some kind of problem with me ?
If so, talk to me, or get professional help, instead of trying to insult
me to the rest of the group.
Grow up!
Ralf
10. 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
11. Re: mainly syntax
>[The tyranny of compare?]
>
>What's wrong with compare? Compare is neccessary because using =,<,> on a
>sequence compares each element of a sequence individually with each
>element in another sequence. This works great for a replacement algorithm
>in this line of code: s = s + ('X'-'x')*(s = 'x') -- this makes all
>occurrences of 'x' into 'X'
Thanks Pete,
I've just downloaded my mail and waded through 286 letters about people
not wanting to type a seven letter word. All I could think of during this
was "My God , I wish all these people would open refman.doc and take a look
at the 'operations on sequences' section."
The '=' operator already performs a very useful task with relation to
sequences. When I first got a PD copy of Eu1.4, it was this very section of
docs that convinced me to invest my time in learning the language. Operations
on sequences are one of Euphoria's great strengths, if you're not using them,
you're missing half the point.
Using the 'end' keyword in sequence slices would make for neater code, but
hardly seems worth saving 6 keystrokes as it would only have to call the length
routine anyway. Unless, of course Eu keeps the length of a sequence it is
working
on somwhere handy during the operation, in which case there could be a time
saving somewhere.
I too would like to see the power() routine replaced with an operator.
Graeme.
12. Re: mainly syntax
At 06:01 PM 2/18/98 +1100, Graeme wrote:
>The '=' operator already performs a very useful task with relation to
>sequences. When I first got a PD copy of Eu1.4, it was this very section of
>docs that convinced me to invest my time in learning the language.
>Operations on sequences are one of Euphoria's great strengths, if you're
>not using them, you're missing half the point.
Way more than half, in my opinion. I don't see those features used
nearly as much as they could be in contributed code.
>Using the 'end' keyword in sequence slices would make for neater code
Yes! Clarity counts, especially six months or five years from now,
when you have to maintain your code. (I still maintain business
programs I wrote 12 years ago - sometimes it's hard to remember
just what a piece of code is supposed to do) Every little bit helps.
>I too would like to see the power() routine replaced with an operator.
The ^ is generally understood to stand for power, and it's not being
used for anything else, is it?
I don't understand the problem with zero - based vs 1 - based indexing,
unless you're trying to use basic code without re-writing. Why would
there be any reason to continually adjust the index s[x-1] ?
What's wrong with calling the first item [1] and the second item [2]...etc.?
Re: Procedures/Functions
I suppose we could replace *procedure foo()* with *void function foo()*,
but where's the gain? The way it is, we don't have to look up each call
to see if it returns anything, and we can't call a function without
actually doing something with the result (kinda important).
One thing that might lead to shorter, clearer code would be to allow
var parameter passing to procedures.
Turbo Pascal allows this, and I use it maybe 10% of the time. Most
of the time, it is because Pascal functions can only return 1 result,
and I need several, so I use a procedure (var a,b,c) instead. Other
times it is because the call is more readable than a function assignment
would be.
Enough...
Irv
----------------------------------------------------------------------------
-----------
Outside an English photographer's studio:
OUT TO LUNCH: IF NOT BACK BY FIVE,
OUT FOR DINNER ALSO
----------------------------------------------------------------------------
-----------
13. Re: mainly syntax
Hello all,
>I don't understand the problem with zero - based vs 1 - based indexing,
>unless you're trying to use basic code without re-writing. Why would
>there be any reason to continually adjust the index s[x-1] ?
>What's wrong with calling the first item [1] and the second item
[2]...etc.?
In real world situations, i.e. memory addressing, certain mathematics,
etc., 0 indexing is used quite a bit. The raycaster demo and the mode19
engine (no plug intended) has to use a lot of x+1 to get the indexing to
work out right in lookup tables. Cos(), Sin(), Tan(), etc. start a 0 not
1. Binary data starts at 0. Most of your algorithms are based on 0
reference. Having to add 1 can be a pain and adds unneeded additions
(lots of them in loops). I would like to see a "Option Base" or similar
so you can start at 1 or 0.
IMHO,
Greg Harris
blackdog at cdc.net
Check out the Euphoria Consortium at:
http://frontpage.cdc.net/blackdog
Under Construction!!
14. Re: mainly syntax
At 11:57 AM 2/18/98 -0500,Greg Harris wrote:
>In real world situations, i.e. memory addressing, certain mathematics,
>etc., 0 indexing is used quite a bit. The raycaster demo and the mode19
>engine (no plug intended) has to use a lot of x+1 to get the indexing to
>work out right in lookup tables. Cos(), Sin(), Tan(), etc. start a 0 not
>1....
Is there some reason to write your own lookup routines
instead of using the built-in cos(), sin(), tan() ?
BTW: real world programming is the Cobol program that writes
your paycheck. The rest is academic... (in more ways than one)
Irv
----------------------------------------------------------------------------
-----------
Outside an English photographer's studio:
OUT TO LUNCH: IF NOT BACK BY FIVE,
OUT FOR DINNER ALSO
----------------------------------------------------------------------------
-----------
15. Re: mainly syntax
> Is there some reason to write your own lookup routines
> instead of using the built-in cos(), sin(), tan() ?
Yes. Speed. Most trig functions calculate the values on the fly, and that's
not what you want in a high-speed programming environment.
> BTW: real world programming is the Cobol program that writes
> your paycheck. The rest is academic... (in more ways than one)
Well, mine is paid by an ACE report interface to Informix Online, but ACE
sure looks like Cobol.
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
16. Re: mainly syntax
Harris, Greg wrote:
>
> Hello all,
>
> >I don't understand the problem with zero - based vs 1 - based indexing,
> >unless you're trying to use basic code without re-writing. Why would
> >there be any reason to continually adjust the index s[x-1] ?
> >What's wrong with calling the first item [1] and the second item
> [2]...etc.?
>
> In real world situations, i.e. memory addressing, certain mathematics,
> etc., 0 indexing is used quite a bit. The raycaster demo and the mode19
> engine (no plug intended) has to use a lot of x+1 to get the indexing to
> work out right in lookup tables. Cos(), Sin(), Tan(), etc. start a 0 not
> 1. Binary data starts at 0. Most of your algorithms are based on 0
> reference. Having to add 1 can be a pain and adds unneeded additions
> (lots of them in loops). I would like to see a "Option Base" or similar
> so you can start at 1 or 0.
When I used look-up tables for my mod player, I often had add 1 to the
index calculated from the mod format, which is predisposed to zero-based
addressing. I believe that most file formats expect zero-based
addressing. The problem with changing Euphoria over to zero-based is that
it would break *all* the code that currently exists. "Option base" might
be a good idea, except how it might affect compatibility with existing .e
files. Also with zero-based indexing, you would have to denote the end
of a slice using length() - 1.
I guess my opinion is that one-based indexing *is* a pain, but the
workaround isn't that difficult... learn to live with it, get used to it,
etc. Changing Euphoria to add zero-based would only compound the problem.
And you can always just use memory if you want zero-based.
> IMHO,
>
> Greg Harris
> blackdog at cdc.net
>
> Check out the Euphoria Consortium at:
> http://frontpage.cdc.net/blackdog
> Under Construction!!
Great site!
[END OF SLICE]
How about a slice end denoted by "..]"? For example,
s = s[2..]
No new keywords, no extra typing for those lazy folks, and it makes sense
to me.
Later,
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
17. Re: mainly syntax
Irv Mullins wrote:
> Is there some reason to write your own lookup routines
> instead of using the built-in cos(), sin(), tan() ?
Let me give my current "real world" example of zero-based indexing.
I'm currently writing a program that reads data from SoundFont files. The
SoundFont file format is a RIFF file format developed by E-mu for
distributing banks of musical instruments, typically stored as digital
samples.
Each instrument in the file is identified by an index. Each instrument
contains one or more layers. Each layer contains one or more zones. Each
zone contains one or more chunks of data: MIDI numbers, sample index, etc.
Guess what: each and every one of these data elements are zero-based
indexes. Even the MIDI number is zero based.
It's difficult enough for my poor little head to keep track of which
particular layer I'm in, to say nothing about having to add an offset to
the reference.
Euphoria doesn't make my job easier. In fact, using Euphoria instead of a
language that allows zero-based indexing makes is *more likely* that my
code will have bugs in it.
I use the same criteria with my complaint of compare(). My basic complaint
isn't that I have to type "compare" instead of "="; it's that time and
again, I've found bugs that stem back to forgetting to include "= 0" after
a compare() statement.
I want a language that makes it more probable that I'll succeed at my task.
For the most part, Euphoria does that well.
-- David Cuny
18. Re: mainly syntax
Pete Eberlein just wrote:
>How about a slice end denoted by "..]"? For example,
>
>s = s[2..]
>
>No new keywords, no extra typing for those lazy folks, and it makes sense
>to me.
A very interesting twist, much better than my original '-1'
suggestion, but I suspect quite unacceptable to people who insist all
keywords must have 7+ letters. Thinking about it now, I like best
David's alternative, simply because it allows more general
shorter/faster/clearer(?) tail indexing, as in, for example,
x = s[end-2], or s = s[3..end-1]
instead of current
x = s[length(s)-2], or s = s[3..length(s)-1]
Thanks, Pete, also for the explanation of the 'foo/bar' thing. Jiri
19. Re: mainly syntax
I was hoping to stay out of these syntax discussions
because I'm trying to get the 2.0 beta out soon, but
you guys have sucked me into it
I can sympathise with most of the complaints.
Language design is very much a matter of compromise,
based on personal biases and experiences.
I can't "prove" that any feature in Euphoria is the best
way to do anything, but I will at least let you know
roughly what I was thinking when I decided on the
features below.
> zero vs. 1-based indexing
Most of my experience is in C programming, and for
C I have absolutely no doubt that 0-based is the way to go.
The equivalence of arrays and pointers, the use
of C for pointing into memory, and for many other reasons
C *must* have 0-based arrays.
When I first started programming in Euphoria
(those were lonely days - I was the only Euphoria programmer
in the world! ) I quickly came to the feeling that the first
element of a sequence s, should be s[1] and the last element
should be s[length(s)], not s[(length(s)-1].
I have not regretted this decision.
I also had an additional flimsy and controversial
notion in my head. I felt that since 0 is a very common
value for a variable to have, 1-based would
catch attempts to subscript with the wrong variable,
if that variable happened to have the value 0. i.e. 1-based
might catch slightly more logic errors than 0-based. This is
admittedly a very weak argument.
In my APL programming days I observed that while
APL gave you a choice between 0 and 1-based indexing
for your program, over 95% of the time people chose to
use 1-based. Euphoria sequences are more like APL "vectors"
than they are like C or BASIC arrays. APL has a rich set of
fancy operations on vectors. One time,
when I had to debug a large 0-based program written by
someone else, I felt very awkward. I had to hesitate at each
subscript and think "Hmmm... we're in 0-based mode, can
I be sure of what's going on here?"
I agree that in maybe 10% of Euphoria programs you would
be better off with 0-based for some of your sequences,
but I think the confusion that it might introduce if Euphoria
allowed you a choice would make "OPTION BASE"
a bad idea overall.
> long keywords - end procedure etc.
That's why "auto-completion" was one of the first
features in ed.ex. Seriously though, you only type
a statement in once. You and possibly others
have to read it many times.
> procedure vs. function
I agree the difference between a procedure and a function
is relatively minor, but "void function" would be more typing than
"procedure" . I think it's useful to distinguish between the two,
so the compiler can catch mismatches between
the use of a routine as a function vs. a procedure.
I know it's a nuisance sometimes to have to assign
the result of a function to "junk" or something.
> x[a..length(x)]
A couple of years ago I almost went ahead and
implemented the thing Pete recently suggested:
x[a..]
i.e., leave off the second index of the slice and it means
"length(x)" by default. I went a step further and thought
that
x[..b] should mean x[1..b]
Then I got tired of the whole idea - why can't someone
type in "1"? Isn't 1..b going to be more readable and only
*one more keystroke?* I moved on to other things.
> compare()
I'm biased here by the fact I have much more
experience in C than BASIC. compare() is analogous
to strcmp() in C. I had already decided that "=" would be
just like "<=" and many other operations in the way
it would apply to entire sequences.
> global exception handler
A lot of people have asked for it.
It's not trivial, but I will look into it
after 2.0 final.
Regards,
Rob Craig
Rapid Deployment Software
20. Re: mainly syntax
At 06:50 PM 2/18/98 -0500, Robert Craig wrote:
>I was hoping to stay out of these syntax discussions
>because I'm trying to get the 2.0 beta out soon, but
>you guys have sucked me into it
>
> <SKIPPED>
> x[a..length(x)]
>
>A couple of years ago I almost went ahead and
>implemented the thing Pete recently suggested:
> x[a..]
>i.e., leave off the second index of the slice and it means
>"length(x)" by default. I went a step further and thought
>that
> x[..b] should mean x[1..b]
>Then I got tired of the whole idea - why can't someone
>type in "1"? Isn't 1..b going to be more readable and only
>*one more keystroke?* I moved on to other things.
>
I don't like the "x[1..]" thing, and x[1..-1] strikes me as pretty bad
also, but it looks to me like there is at least a little bit of consensus
on the list about adding the x[1..end] form, like in PP, to the built-in
parts of Euphoria. That I heartily agree with. Using "end" in that
particular place is slightly easier to type and MUCH clearer.
No, scrap the "slightly"; some guys have been using examples like
x[1..length(x)]
to demonstrate how it's not really that hard to type the function call
'length(x)' but that's not the problem; the problem is typing something like
cur_buf = storage_buf[10..length(storage_buf)]
over and over. Yes, I can predict the comments of Real Programmers about
following book recommendations too much and using over-long variable names,
but jeez . . . not *everything* can have a one-letter identifier! Well, it
can (26 of'em, anyway), but any non-trivial program written that way better
have a butt-load of comments if the programmer following you is to have the
slightest chance of maintaining your code without developing a serious
drinking habit.
Besides, it's not necessarily *your* code you need to worry about; suppose
you download some code that works well, but when you take a look at it, it
turns out the coder was in favor of sentences rather than names; would you
rather have to look at
current_editing_buffer =
or
current_editing_buffer = permanent_storage_buffer[10..end]
Still irritatingly overlong, but as someone else said, every little bit
helps (as long as it's clear).
Anyway, back to the point; I'm strongly in favor of the x[1..end] form,
and I hope enough others are to persuade Mr. Craig to think about it
putting it in another release down the line. However, I know nothing about
the guts of an interpreter (or compiler); would that be a Bad Thing to try
to add to the built-ins, in light of 'end' already being rather extensively
used in the block constructs?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
J. Craig Gilbert
cgilbert at mc.peachnet.edu
"Positing infinity, the rest is easy."
Roger Zelazny, in
'Creatures of Light and Darkness'
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
21. Re: mainly syntax
- Posted by Jacques Deschenes <desja at GLOBETROTTER.QC.CA>
Feb 18, 1998
-
Last edited Feb 19, 1998
At 18:03 17-02-98 -0800, you wrote:
>[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.
>
David,
when you use all those ..Indirect() win32 api functions , like CreateFontIndi
rect() beware that some fields of the structure may need to be double word ali
gned. When I was writing some code using CreateDialogIndirect() I had really ha
rd time to find why it wasn't working. After hours of testing and reading and re
-reading win32.hlp, I realised mostly by luck that some elements of the structu
re needed double word aligment and that was not written in win32.hlp
I didn't tested it for LOGFONT sructure but my guess is that lf.lfFaceName need
to be doubleword aligned (because it correspond to *char[] in C)
Or maybe the whole structure need to be doubleword aligned.
Hoping this may help,
Regards,
Jacques Deschenes
Baie-Comeau, Quebec
Canada
desja at globetrotter.qc.ca
22. Re: mainly syntax
Nobody seemed to mention the elegant solution to the
foo=append(foo,bar)
problem as applied in PP. You can write
foo =a bar
or
foo =& bar
if you want to concatenate. This provides nice efficient, non-irritating code
like in C.
Daniel Johnson
23. Re: mainly syntax
> [ q &= r ]
> if you want to concatenate. This provides nice efficient, non-irritating code
> like in C.
I think what Robert is trying to say is that he doesn't want to turn Euphoria
into C. C's strength and C's weakness both are that it's terse as hell.
I think some added clarity beat ease of typing in the long run.
That having been said, I do like the idea of q &= r, but do we need it?
--
Cameron Kaiser * spectre at sserv.com * http://www.sserv.com/
--
Visit the leading Internet starting point today!
http://www.sserv.com/
--
