1. Py Update
For anyone interested in Py (my Euphoria/Python hybrid language), there's an
update available at:
http://www.lanset.com/dcuny/py.htm
New features include:
- supports most of Euphoria's core routines
- associated lists (dictionaries)
- 'continue' statement for loops
- 'else' clauses for loops
- more bugfixes
- documentation
I've also written a support program making it easy to create wrappers to
Euphoria libraries. For example, it can wrap the Win32Lib library.
Unfortunately, Py doesn't support callbacks (yet), so it can't do much more
than create windows with controls.
As always, feedback is appreciated.
-- David Cuny
2. Re: Py Update
On 20 Oct 2000, at 2:55, David Cuny wrote:
>
> As always, feedback is appreciated.
Does it have a "goto"? 
Kat
3. Re: Py Update
Kat wrote:
> Does it have a "goto"?
I *knew* you would ask that!
No, the issue is that I've implemented that internal representation
(including nested structures) using nested sequences. If I had used
bytecodes instead, it would have been trivial.
Maybe I'll go to bytecode.
Thanks!
-- David Cuny
4. Re: Py Update
On 20 Oct 2000, at 10:12, David Cuny wrote:
> Kat wrote:
>
> > Does it have a "goto"?
>
> I *knew* you would ask that!
>
> No, the issue is that I've implemented that internal representation
> (including nested structures) using nested sequences. If I had used
> bytecodes instead, it would have been trivial.
>
> Maybe I'll go to bytecode.
If you can, then "case - end case" would be trivial and faster too, yeas?
case WonderWhatThisIs :
"hello" : procedure greet
iswm(*thanks*) : procedure thanks
-- 5000 other tests
end case
after each test is an implied goto(end case), so the other 5000 tests need not
be done.
This would replace the big
if ( ) -- code
elsif ( ) -- code
elsif ( ) -- code
elsif ( ) -- code
-- 50 more elsif()
end if
stack i have in one app now. But the current "if" stack does work fine now.
"exit" would be easier to do also, you'd have all the exits people have asked
for,
exit(for)
exit(if)
exit(procedure)
exit(function)
exit(repeat)
all would be a *local* goto in disguise. I said *local* to procedure or
function, jumps
outside local should be illegal, imho, just 'cause of complexity.
Kat,
just thinking out loud here atm.
5. Re: Py Update
Kat wrote:
>> Maybe I'll go to bytecode.
>
> If you can, then "case - end case" would be
> trivial and faster too, yeas?
No, it would be 90% the same as the If code. The real work would be at the
grammar level, so that stuff like this would parse properly:
case is > 23 or is < 22:
case 1,2,3:
case 90 to 100:
Bleah. I don't really think that there's *that* much need for a Case
statement, though. Basically, you can just write:
object is
is = <expr>
if is = 12 then
...
elsif is = 33 then
...
end if
and get the same sort of thing.
> exit(for)
> exit(if)
> exit(procedure)
> exit(function)
> exit(repeat)
If you had a goto, there really wouldn't be any need for all these exits
anyway. I suspect that I'm not likely to make the jump to 'flat' opcodes,
since I suspect that the resulting code would actually run a bit slower -
there would be more granularity to the instructions, and less of a 1:1
mapping to Euphoria.
One thing I *could* do is add a pop() statement, that would 'pop' out of 'n'
levels of instructions. The problem here is that it's *way* too easy to mess
up with something like that. Add an additional test, and you've changed the
nesting count. Blooey goes the code.
Thanks!
-- David Cuny
6. Re: Py Update
Great work David.
Seeing its still in alpha-mode, can I suggested a change or two?
Allow the programmer to decide whether or not to allow automatic creation of
variables. Some programmers like variables to be created automatically and
others believe that this is another source of potential bugs.
My personal preference is to have to declare variables before they can be
referenced. This way I can catch all my spelling mistakes.
If I coded the following function this way, it would always fail, simply
because I misspelt the return name.
def find_match( list, key )
matches = 0
for item in list do
if key = item then
matches += 1
end if
end for
return matchs
end def
So how about a language directive like one finds in MS Basic "option
explicit".
And how about allowing a "while" clause in the "for" statement.
-- See if there is at least 5 items greater than 4.
for item in list
while item > 4 and matches < 5
do
if key = item then
matches += 1
end if
end for
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
7. Re: Py Update
Derek Parnell wrote:
> Great work David.
Thanks!
> Seeing its still in alpha-mode, can I suggested a change or two?
Sure, but one of my goals (like Euphoria) is to keep Py relatively small.
For example, I'm giving serious consideration to removing the 'else' clause
from loops...
> Allow the programmer to decide whether or not to
> allow automatic creation of variables.
I think there is some confusion. Py only creates a variable when a value has
been assigned to it. So if you try to use a variable without first assigning
a value, you get an error.
> If I coded the following function this way, it would always fail, simply
> because I misspelt the return name.
>
> def find_match( list, key )
> matches = 0
> for item in list do
> if key = item then
> matches += 1
> end if
> end for
> return matchs
> end def
Did you try this example in Py? It catches 'matchs' as an undeclared
variable.
> And how about allowing a "while" clause in the "for" statement.
>
> -- See if there is at least 5 items greater than 4.
> for item in list
> while item > 4 and matches < 5
> do
> if key = item then
> matches += 1
> end if
> end for
I'm confused how this different from:
for item in list do
if item > 4 and then
matches += 1
if matches > 4 then
exit
end if
end if
end for
or why it deserves a special case.
Thanks!
-- David Cuny
8. Re: Py Update
----- Original Message -----
From: "David Cuny" <dcuny at LANSET.COM>
> > Allow the programmer to decide whether or not to
> > allow automatic creation of variables.
>
> I think there is some confusion. Py only creates a variable when a value
has
> been assigned to it. So if you try to use a variable without first
assigning
> a value, you get an error.
Yeah, I did get confused about that. So every variable must have an
assignment. This is then similar to a declare statement except that there is
no datatype. This should suffice I expect.
>
> Did you try this example in Py? It catches 'matchs' as an undeclared
> variable.
No I haven't tried it yet. I *REALLY* wish to release win32lib v0.54 this
weekend.
> > And how about allowing a "while" clause in the "for" statement.
> >
> > -- See if there is at least 5 items greater than 4.
> > for item in list
> > while item > 4 and matches < 5
> > do
> > if key = item then
> > matches += 1
> > end if
> > end for
>
> I'm confused how this different from:
>
> for item in list do
> if item > 4 and then
> matches += 1
> if matches > 4 then
> exit
> end if
> end if
> end for
>
> or why it deserves a special case.
No, it isn't different. Just some syntactic sugar. You know us lazy
programmers - hate to waste time and effort with keystrokes and verbosity.
(Boy, did hate using COBOL!)
------
Derek Parnell
Melbourne, Australia
(Vote [1] The Cheshire Cat for Internet Mascot)
9. Re: Py Update
hi, derek
thanks, i'll have it on my site in a few minutes, and then stagger to bed -
it's four in the morning here.
you can also find the new version (2.2a) posted; i've made a number of
corrections to the code based on bugs that irv found.
-- david
10. Re: Py Update
This Py language can't be a seriuos project? Cause you would have to write
it in C not Euphoria for the sake of speed. So I'm assuming you are writing
it ... why?
Why don't you write a preprocessor (upgrade existing).
It would make much more sense and it would be useful for some real programs.
It would be very interesting to have our own language similar to Euphoria
with source code available.
11. Re: Py Update
=A9koda wrote:
> This Py language can't be a serious project?
Oh?
> Cause you would have to write it in C not Euphoria
> for the sake of speed.
There are quite a few languages written in "high level" languages that ru=
n
just fine. Squeak, for example. With processor speeds as high as they are=
,
it's getting harder and harder to accept that premise.
> So I'm assuming you are writing it ... why?
Well, I compared the Queens demo program written in Euphoria and Py.
Benchmarks on my machine look something like:
Interpreted Py: 18 seconds
Bound Py: 12 seconds
Compiled Py: 7 seconds
Interpreted Euphoria: 2 seconds
Compiled Euphoria: 2 seconds
By the way, I'd be careful about comparing the benchmark programs that co=
me
with Euphoria to Py - they tend to use operations which are optimized to
specific data types, and Py only uses objects.
> Why don't you write a preprocessor (upgrade existing).
I'd written a preprocessor for Euphoria some time back. An interpreter is=
a
lot more flexible. For example, implementing a 'continue' statement is
difficult to do in a pre-processor. You can also do a lot more 'meta' typ=
e
stuff, like finding out what sort of variables are in a module, what
variable values are, evaluting statements, create variables dynamically...
the kind of stuff that Kat keeps asking for.
> It would make much more sense and it would be useful
> for some real programs.
I'm not convinced that my approach is a bad thing. I reserve the right to
change my mind, though.
> It would be very interesting to have our own language
> similar to Euphoria with source code available.
Peuphoria, which is in 'pure' C. The source code is available, and Menno =
has
been working on fixing the remaining bugs.
-- David Cuny
12. Re: Py Update
- Posted by Irv <irv at ELLIJAY.COM>
Oct 21, 2000
-
Last edited Oct 22, 2000
On Sat, 21 Oct 2000, <tone.skoda at SIOL.NET> wrote:
> This Py language can't be a seriuos project? Cause you would have to write
> it in C not Euphoria for the sake of speed. So I'm assuming you are writing
> it ... why?
Dave Cuny is writing it - and after playing with it for a few minutes, I'd have
to say, yes, it is a very serious project.. In an amazingly short period of
time, he has added a lot of the features that people have been asking for on
this list for years. It's already fast enough for many uses, even though
it uses Euphoria as its base - and the Euphoria engine can be compiled,
further boosting the speed.
> Why don't you write a preprocessor (upgrade existing).
> It would make much more sense and it would be useful for some real programs.
There are a number of preprocessors available already. They aren't used very
much, as far as I can see. Personally, they annoy me more than help.
Besides, I don't know how a pre-processor would let you run in interactive
mode. (I thought I would hate this, but it turns out to be quite useful)
> It would be very interesting to have our own language similar to Euphoria
>with source code available.
Dave supplies everything you need to write your own. Give it a try.
Or, better, contribute to testing Py - perhaps some of the neat features
will be enough to convince Rob to add them to Euphoria.
Regards,
Irv
13. Py Update
I've posted yet another (source only) update to Py on my home page:
http://www.lanset.com/dcuny/py.htm
This takes care of some parse errors with numbers, so slices should work
again. It also implements the new (and mostly untested) namespace, which
gets rid of the OOP-ish tricks that could be done with namespaces (sorry,
Irv).
Before getting to worked up about the changes to the namespace behavior,
keep in mind that the next item on the 'to do' list is objects (using
association lists), so you can do *real* OOP, with dynamic lookup of values
and methods.
I'll also try to get some sort of 'sanity' program written, so I can
automatically check for obvious bugs before posting this stuff.
As usual, bug reports are appreciated (and expected).
-- David Cuny
