1. Pike
I ran across a language called Pike at:
http://pike.idonex.se/
[ Feature Creep ]
It's essentially an interpreted flavor of C, and resembled Euphoria in a lot
of ways. Some of the features implemented in the language:
foreach( array, variable )
and:
s = s[..5] + "w" + [7..]
[ Classes For Euphoria ]
I think the way that Pike implements classes was rather clever, and might be
useable by Euphoria. I'll borrow an paragraph from the Pike manual:
Think of the data type program as an executable file. Then we clone this
program and create an object. The object is then a running program. The
object has its own data and its own functions, however, it can work together
with other programs by calling functions in those objects. The functions can
be thought of as message carriers, TCP sockets or just a way for programs to
communicate. Now we have a running system with many running programs, each
performing only the task it was designed for. This analogy has one major
flaw, when running programs in UNIX they actually run simultaneously. UNIX
is multitasking, Pike is not. When one object is executing code, all the
other objects has to wait until they are called. An exception is if you are
using threads as will be discussed in a later chapter.
Think of this in Euphoria terms. Include files *are* declarations of classes
- it just happens that it's a declaration of a single, unnamed instance of
the class:
module variable = object attribute
module function and procedure = object method
Since the "include" keyword currently creates an unnamed instance of a
class, we run into the problem of namespace. Naming include files gets rid
of this problem, but could make Euphoria code look like Java (*shudder*):
Output.puts( Screen, "hello, world!\n" )
Add "cloning" to namespaces, and you have something that behaves an awful
lot like OOP:
Fred = clone( Window )
Fred.setSize( 10, 10, 200, 330 )
Fred.setTitle = "hello, world!"
Fred.show()
I'm assuming that there's a 'self' variable in these examples...
[ What About Polymorphism and Type Checking? ]
Although polymorphism seems like a good thing to have, I can't imagine it
being added to Euphoria without signifigantly altering the language. The
issue is that routines have to be resolved at run-time. But classes can be
added to Euphoria without making it polymorphic. Take the trivial example:
procedure foo( Window theWindow )
theWindow.bar()
end procedure
The procedure call 'theWindow.bar' can be resolved at compile time as
Window.bar. Given an inheritance tree like this:
ModalWindow -> Window -> Canvas -> Generic
any objects of type ModalWindow and Window would could be passed to foo,
while any other class would fail the type check. GTK+ is a class-based C
library that uses a similar form of type checking.
I know I'm glossing over a couple of details, but it *seems* like a fairly
good fit.
Comments?
-- David Cuny
2. Re: Pike
Pike looks like it's for unix type os
note the ver# .6
It is in beta so how many features are only I wish we coulds ?
3. Re: Pike
Bernie Ryan wrote:
> Pike looks like it's for unix type os
> note the ver# .6
> It is in beta so how many features are
> only I wish we coulds ?
The features (as best as I can tell) are all implemented and non-vaporware.
And yes, it's UN*X only. There seems to be some (slightly familiar) debate
in the Pike community about how best to port it to various platforms.
But those are incidental to the question I had in mind; I was wondering
about what people thought about adopting a Pike-like approach to classes.
-- David Cuny
4. Re: Pike
- Posted by Bernie Ryan <bwryan at PCOM.NET>
May 27, 1999
-
Last edited May 28, 1999
I'am for anything that gives more control over the scope ( nesting,
namespace, classes, etc.) and also I want DLL support in DOS which
PMODE, DOS32, & WDOSX dos extenders support and I guess Rob's
extender does not support.
5. Re: Pike
Hmmmmm, under the testimonials, the question "What is the sexiest thing
about Pike? ". OK, what's this with EU and Pike wanting to be so sexy? Is
there anything sexy about a programming lang? Should I ask my wife to wear
EU instead of a negligée?
-----Original Message-----
From: Cuny, David <David.Cuny at DSS.CA.GOV>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Thursday, May 27, 1999 5:13 PM
Subject: Pike
>I ran across a language called Pike at:
>
> http://pike.idonex.se/
>
>[ Feature Creep ]
>
>It's essentially an interpreted flavor of C, and resembled Euphoria in a
lot
>of ways. Some of the features implemented in the language:
>
> foreach( array, variable )
>and:
>
> s = s[..5] + "w" + [7..]
>
>
>[ Classes For Euphoria ]
>
>I think the way that Pike implements classes was rather clever, and might
be
>useable by Euphoria. I'll borrow an paragraph from the Pike manual:
>
>
>Think of the data type program as an executable file. Then we clone this
>program and create an object. The object is then a running program. The
>object has its own data and its own functions, however, it can work
together
>with other programs by calling functions in those objects. The functions
can
>be thought of as message carriers, TCP sockets or just a way for programs
to
>communicate. Now we have a running system with many running programs, each
>performing only the task it was designed for. This analogy has one major
>flaw, when running programs in UNIX they actually run simultaneously. UNIX
>is multitasking, Pike is not. When one object is executing code, all the
>other objects has to wait until they are called. An exception is if you are
>using threads as will be discussed in a later chapter.
>
>
>Think of this in Euphoria terms. Include files *are* declarations of
classes
>- it just happens that it's a declaration of a single, unnamed instance of
>the class:
>
> module variable = object attribute
> module function and procedure = object method
>
>Since the "include" keyword currently creates an unnamed instance of a
>class, we run into the problem of namespace. Naming include files gets rid
>of this problem, but could make Euphoria code look like Java (*shudder*):
>
> Output.puts( Screen, "hello, world!\n" )
>
>Add "cloning" to namespaces, and you have something that behaves an awful
>lot like OOP:
>
> Fred = clone( Window )
> Fred.setSize( 10, 10, 200, 330 )
> Fred.setTitle = "hello, world!"
> Fred.show()
>
>I'm assuming that there's a 'self' variable in these examples...
>
>
>[ What About Polymorphism and Type Checking? ]
>
>Although polymorphism seems like a good thing to have, I can't imagine it
>being added to Euphoria without signifigantly altering the language. The
>issue is that routines have to be resolved at run-time. But classes can be
>added to Euphoria without making it polymorphic. Take the trivial example:
>
> procedure foo( Window theWindow )
> theWindow.bar()
> end procedure
>
>The procedure call 'theWindow.bar' can be resolved at compile time as
>Window.bar. Given an inheritance tree like this:
>
> ModalWindow -> Window -> Canvas -> Generic
>
>any objects of type ModalWindow and Window would could be passed to foo,
>while any other class would fail the type check. GTK+ is a class-based C
>library that uses a similar form of type checking.
>
>I know I'm glossing over a couple of details, but it *seems* like a fairly
>good fit.
>
>Comments?
>
>-- David Cuny
