new language (it's me again): original idea? 
Author Message
 new language (it's me again): original idea?

Hi,
    Some of you may remember i'm interested in designing a new language and
was looking for ideas.  Well I came up with something and thought I'd share
it with the world.  Hmm, where shall I start?

Languages like Ada, Pascal and [x | x <- ["C(++)","Java"], x == pants] are
block structured.   In this structure all statements are executed in a
linear fashion (no I haven't forgot about 'if .. then' and such like).

e.g.
    procedure do_something is
    begin
        do_a;
        do_b;
        do_c;
    end do_something; -- can ya tell what it is yet?

This means do_a, then do_b, then do_c one after another in sequence.

{I know functional languages are a little (or perhaps a lot) different but
let's leave them out of this for now}

I've used block structured languages, but i'm having a hard time describing
them.  Anyway it's not really important, it is the linear execution concept
we need for this.

Let me give you an example before I start bletherin' on about this language
idea.

    procedure do_something_else is
    begin
        [       buy card,
                buy present,
                buy flowers,
                take to dinner,
                get snog,
                use your imagination
        ];
    end do_something_else; -- since it's St. Valentine's day

Basically this executes linearly,

    1. buy a card
    2. buy a present
    3. buy flowers
    4. take your partner to dinner in a fancy restaurant
    5. get a snog (or get niped as we say in Scotland)
    6. etc

Things need not be done in this order though.  You could do 2 before 1, for
example.  I.e. Somethings are independant and can be done in any order.

Hmm, I've got a wiff of another example

    procedure st_valentines  is
    begin
        [       {          buy card,
                            buy present,
                            buy flowers
                },
                take to dinner,
                get snog,
                use your imagination
        ];
    end st_valentines;

This says you must buy a card, present and flowers in any order you like.
The only requirment is that you do so before dinner (otherwise he/she's
gonna get someone else, and that's bad folks).  You could even do them at
the same time.

The point is you have the flexibility to specify the order of execution (you
get this anyway), but you can choose to leave the order of execution of
parts of a routine (or whatever) upto compiler (or perhaps even the routine
itself).  All that matters is they get executed before the continuation of
the linear sequence of which they are part.

I know about threads and tasks, I don't think the concept is the same but
it's certainly related.  For example I could specify which parts need to be
done sequentially and which can be done in parallel.  I know people are
spending lifetimes trying to find out how to determine which parts of
programs can be run independantly and in parallel.  I don't propose this as
a solution to this problem, and it's not meant to be.

I thought this crazy idea up in class today and maybe it's just not a good
idea, what do you think?

Thanks for listening,
Chris Campbell



Mon, 04 Aug 2003 04:42:53 GMT  
 new language (it's me again): original idea?
I neglected something important!

In st_valentines those routines in {  } should only be executed once,

     procedure st_valentines  is
     begin
         [       {          buy card,
                             buy present,
                             buy flowers
                 },
                 take to dinner,
                 get snog,
                 use your imagination
         ];
     end st_valentines;

you don't want to buy more than one present, card, or more than one bunch of
flowers, do you?
not unless you've got money to burn, or someone worth who's it.

from a programming point of view though it's not o.k.

right that's that sorted,
Chris Campbell



Mon, 04 Aug 2003 05:28:55 GMT  
 new language (it's me again): original idea?

Quote:
> The point is you have the flexibility to specify the order of
> execution (you get this anyway), but you can choose to leave the
> order of execution of parts of a routine (or whatever) upto compiler
> (or perhaps even the routine itself).

For functional code the order of evaluation does not matter and
most (?) languages don't specify in which order subexpressions are
evaluated.

But I haven't heard about a concrete implementation of a language
which executes things in parallel without hints from the programmer.
Surely there was some research on this.

Quote:
> I know about threads and tasks, I don't think the concept is the
> same but it's certainly related.

What is the difference for imperative code? I can write your code in
Concurrent Haskell with no difficulty:

st_valentines = do
    parallel [buy card, buy present, buy flowers]
    take to dinner
    get snog
    use your imagination

parallel :: [IO a] -> IO [a]
-- This helper function is not provided by standard concurrent
-- libraries, but could be.
parallel fs =
    sequence [do
        v <- newEmptyMVar
        forkIO (f >>= putMVar v)
        return v
        | f <- fs]
    >>= mapM takeMVar

--

 \__/
  ^^                      SYGNATURA ZASTPCZA
QRCZAK



Mon, 04 Aug 2003 05:34:06 GMT  
 new language (it's me again): original idea?

Well, you wanted to avoid functional languages, but you're going to end
up there :-)

The only way to make this simple is to make sure that nothing has "side
effects".  If buying the flowers makes you sneeze so much you can't buy
the card, you have problems, for example.  What I mean is, everything
has to be clear - you can't go and have buying flowers setting some
global "sneeze" variable that the buying the card routine might check
and complain about.

Anyway, if you drop side effects you are effectively using a functional
language (in one sense).  And if you really really really drop side
effects then you're using a pure functional language.  And Haskell is a
pure functional language and it works like you suggested - kind of.  The
way it does things is to not actually execute anything til it's needed.
So neither buying the card nor the flowers are actually executed (even
though you defined them) until you give the card or the flowers (which
is when you need them!).

In theory it should make some programs more efficient, because if you
never need something you never do it.  In practice, it's a mixed
blessing.

Haskell is a nice language though.  I'm playing with it at the moment.

www.haskell.org

Andrew

Quote:

> Hi,
>     Some of you may remember i'm interested in designing a new language and
> was looking for ideas.  Well I came up with something and thought I'd share
> it with the world.  Hmm, where shall I start?

> Languages like Ada, Pascal and [x | x <- ["C(++)","Java"], x == pants] are
> block structured.   In this structure all statements are executed in a
> linear fashion (no I haven't forgot about 'if .. then' and such like).

> e.g.
>     procedure do_something is
>     begin
>         do_a;
>         do_b;
>         do_c;
>     end do_something; -- can ya tell what it is yet?

> This means do_a, then do_b, then do_c one after another in sequence.

> {I know functional languages are a little (or perhaps a lot) different but
> let's leave them out of this for now}

> I've used block structured languages, but i'm having a hard time describing
> them.  Anyway it's not really important, it is the linear execution concept
> we need for this.

> Let me give you an example before I start bletherin' on about this language
> idea.

>     procedure do_something_else is
>     begin
>         [       buy card,
>                 buy present,
>                 buy flowers,
>                 take to dinner,
>                 get snog,
>                 use your imagination
>         ];
>     end do_something_else; -- since it's St. Valentine's day

> Basically this executes linearly,

>     1. buy a card
>     2. buy a present
>     3. buy flowers
>     4. take your partner to dinner in a fancy restaurant
>     5. get a snog (or get niped as we say in Scotland)
>     6. etc

> Things need not be done in this order though.  You could do 2 before 1, for
> example.  I.e. Somethings are independant and can be done in any order.

> Hmm, I've got a wiff of another example

>     procedure st_valentines  is
>     begin
>         [       {          buy card,
>                             buy present,
>                             buy flowers
>                 },
>                 take to dinner,
>                 get snog,
>                 use your imagination
>         ];
>     end st_valentines;

> This says you must buy a card, present and flowers in any order you like.
> The only requirment is that you do so before dinner (otherwise he/she's
> gonna get someone else, and that's bad folks).  You could even do them at
> the same time.

> The point is you have the flexibility to specify the order of execution (you
> get this anyway), but you can choose to leave the order of execution of
> parts of a routine (or whatever) upto compiler (or perhaps even the routine
> itself).  All that matters is they get executed before the continuation of
> the linear sequence of which they are part.

> I know about threads and tasks, I don't think the concept is the same but
> it's certainly related.  For example I could specify which parts need to be
> done sequentially and which can be done in parallel.  I know people are
> spending lifetimes trying to find out how to determine which parts of
> programs can be run independantly and in parallel.  I don't propose this as
> a solution to this problem, and it's not meant to be.

> I thought this crazy idea up in class today and maybe it's just not a good
> idea, what do you think?

> Thanks for listening,
> Chris Campbell



Mon, 04 Aug 2003 05:58:42 GMT  
 new language (it's me again): original idea?



Quote:

> Hi,
>     Some of you may remember i'm interested in designing a new language
and
> was looking for ideas.  Well I came up with something and thought I'd
share
> it with the world.  Hmm, where shall I start?

> Languages like Ada, Pascal and [x | x <- ["C(++)","Java"], x == pants] are
>..............................

Hi!
I'm afraid all HLLs make the programmer believe to have the opportunity
to choose between serial and parrallel programm-sequences.
As long there is only one Cpu inside, the programm-sequence is always
one opcode-line after the other.
The so called multitasking is in fact nothing else than time-slicing, and
the so beloved taskswitches often needs more time then the programm-
task itself.

A good language must satisfy the programmers needs (or wishes).

The main problem are the compilers, they aren't smart enough to produce
really effective code.

kind regards
wolfgang



Mon, 04 Aug 2003 07:31:54 GMT  
 new language (it's me again): original idea?

I must be explaining something wrong somewhere.  The reason I don't want to
discuss FP is because i know they don't have side effects(for the most
part).  Leave them alone for 5 minutes please.

The idea is to allow a certain freedom to the compiler or routine or
whatever.  Also it tells the programmer what parts of the program are
disjoint (independant of each other), which is most important IMO.

Forget parallel execution for now.  When i write programs there is almost
always (small) parts of code which do not depend on each other, which can be
done in any order.  Irrespective of the order they are performed in they
must all be complete before another part of the program which is dependant
on those (independant) routines.  Suppose B was a short routine and A was a
long one.  So long as they're independant of each other we can do them in
any order we like.  We could do B first, since it's shorter, and then do A.
Since there are only two in this example it's hard to see but imagine we had
10 independant tasks of varying execution time.  Can you keep track of all
independant routines in your programs?  Surely at least telling youself that
A, B are separate and independant would help.  It becomes instantly
recognisable and you don't have to work so hard.

What i propose is to that the programmer specifies which parts are
independant of each other and it's upto the environment in which order they
get done.

{}     this is a sequence of events which can take place in any order (but
all must be done).
[]      this is a sequence of events which take place in a specific ordered
way.

[ {A, B}
    C
]

that means do A, B and C
but it tells us that A and B are independant
and thus can be executed in any order

C is dependant on A and B so both must be done before C.

So we can do A, B in any order as long as they get executed before C.

E.g.
    let x = 10, y = 20

    procedure something
    [
        {p = x/4; q = y/3}
        r = p/q;
    ]

we should know that p & q are independant so why not tell the compiler (or
system) so, it's not smart enough to know that itself [maybe in this case it
could; for a more complex system(bucket loads of lines) it may not]

It's not really about parallel execution, it's about code execution order.
It can be used for parallel processing, but that's not it's function.

It 10.51 and i'm knackered, bye
Chris Campbell

p.s. Haskell is great fun (I'd advise anyone who reads this to learn it)
      So is Ada 95, you could learn it too.


Quote:

> Well, you wanted to avoid functional languages, but you're going to end
> up there :-)

> The only way to make this simple is to make sure that nothing has "side
> effects".  If buying the flowers makes you sneeze so much you can't buy
> the card, you have problems, for example.  What I mean is, everything
> has to be clear - you can't go and have buying flowers setting some
> global "sneeze" variable that the buying the card routine might check
> and complain about.

> Anyway, if you drop side effects you are effectively using a functional
> language (in one sense).  And if you really really really drop side
> effects then you're using a pure functional language.  And Haskell is a
> pure functional language and it works like you suggested - kind of.  The
> way it does things is to not actually execute anything til it's needed.
> So neither buying the card nor the flowers are actually executed (even
> though you defined them) until you give the card or the flowers (which
> is when you need them!).

> In theory it should make some programs more efficient, because if you
> never need something you never do it.  In practice, it's a mixed
> blessing.

> Haskell is a nice language though.  I'm playing with it at the moment.

> www.haskell.org

> Andrew



Mon, 04 Aug 2003 06:54:09 GMT  
 new language (it's me again): original idea?
I hardly ever use threads, or multitasking.  Mostly because it's not been
necessary thus far.

I do know that computers such as PC's only have one CPU and that they can do
only one task at a time.  I think everyone's missing the point.

Or maybe i'm just being daft.

Let me ask you this.  What would the benefit be to a programmer if she knew
what parts of the routine were (should be) independant of each other?

Chris Campbell



Mon, 04 Aug 2003 07:04:41 GMT  
 new language (it's me again): original idea?
chris> I hardly ever use threads, or multitasking.  Mostly because
chris> it's not been necessary thus far.

chris> I do know that computers such as PC's only have one CPU and
chris> that they can do only one task at a time.  I think everyone's
chris> missing the point.

chris> Let me ask you this.  What would the benefit be to a programmer
chris> if she knew what parts of the routine were (should be)
chris> independant of each other?

It is readily discussed by looking at a spreadsheet; if you change a
value in one location, which results in many other dependent values
changing, it becomes beneficial for there to be a "display thread" as
well as a "calculation thread" as well as a "user input thread."

After all, you can continue calculating on the cells that are not
being displayed in the background whilst the user is thinking about
what to type next.

Or, supposing you're implementing a text editor.  It is attractive to
have a thread go off and save the file periodically whilst the user is
rapt in thought.  

It is also a good idea to have a thread that's watching for keyboard
input so that if the system is busy working on saving a big file to a
slow disk, you can still collect up changes so that when the "save"
operation completes, none of the user's typing is lost.
--

http://vip.hex.net/~cbbrowne/sap.html
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"



Mon, 04 Aug 2003 07:54:57 GMT  
 new language (it's me again): original idea?

Quote:

>     procedure st_valentines  is
>     begin
>         [       {          buy card,
>                             buy present,
>                             buy flowers
>                 },
>                 take to dinner,
>                 get snog,
>                 use your imagination
>         ];
>     end st_valentines;

Change the punctuation around a little and you're pretty close to Algol68.

Quote:
> This says you must buy a card, present and flowers in any order you like.
> The only requirment is that you do so before dinner (otherwise he/she's
> gonna get someone else, and that's bad folks).  You could even do them at
> the same time.

Or "collaterally", as the Algol literature puts it.


Mon, 04 Aug 2003 17:21:09 GMT  
 new language (it's me again): original idea?

Quote:

> I must be explaining something wrong somewhere.  The reason I don't want to
> discuss FP is because i know they don't have side effects(for the most
> part).  Leave them alone for 5 minutes please.

> The idea is to allow a certain freedom to the compiler or routine or
> whatever.  Also it tells the programmer what parts of the program are
> disjoint (independant of each other), which is most important IMO.

But imagine using an imperative language where you specify that some
sections can be run in any order - with no language features to help you
be sure that there were no side efffects you'd end up with either not
using the indeterminism or having hoorible bugs.

Have you done any multi-threaded programming in imperative languages?
You get the most horrible bugs because of just this.

Andrew



Mon, 04 Aug 2003 17:40:56 GMT  
 new language (it's me again): original idea?

Quote:

>     procedure st_valentines  is
>     begin
>         [       {          buy card,
>                             buy present,
>                             buy flowers
>                 },
>                 take to dinner,
>                 get snog,
>                 use your imagination
>         ];
>     end st_valentines;

There are quite a few imperative languages that provide this type of construct,
I'd suggest having a look at occam.

JonB.



Mon, 04 Aug 2003 19:49:36 GMT  
 new language (it's me again): original idea?

Quote:


> > I must be explaining something wrong somewhere.  The reason I don't want to
> > discuss FP is because i know they don't have side effects(for the most
> > part).  Leave them alone for 5 minutes please.

> > The idea is to allow a certain freedom to the compiler or routine or
> > whatever.  Also it tells the programmer what parts of the program are
> > disjoint (independant of each other), which is most important IMO.

> But imagine using an imperative language where you specify that some
> sections can be run in any order - with no language features to help you
> be sure that there were no side efffects you'd end up with either not
> using the indeterminism or having hoorible bugs.

> Have you done any multi-threaded programming in imperative languages?
> You get the most horrible bugs because of just this.

It depends, as long as you use proper synchronisation primitives (locks,
semaphores, critical regions etc) you shouldn't have any problems.

JonB.

- Show quoted text -

Quote:

> Andrew



Mon, 04 Aug 2003 19:52:03 GMT  
 new language (it's me again): original idea?

Quote:

> I hardly ever use threads, or multitasking.  Mostly because it's not been
> necessary thus far.

> I do know that computers such as PC's only have one CPU and that they can do
> only one task at a time.  I think everyone's missing the point.

> Or maybe i'm just being daft.

> Let me ask you this.  What would the benefit be to a programmer if she knew
> what parts of the routine were (should be) independant of each other?

> Chris Campbell

Threads are very useful in event driven programs, such as those that contain
GUIs or client/server type programs. E.g. For a web server, the actions of one
client are pretty much independant from the actions of others. It makes coding
a lot simpler if one thread is allocated to each client, because the code only
has to deal with communicating with one client.

Besides, just because your machine only has one CPU, it doesn't mean that
everone elses does.

JonB.



Mon, 04 Aug 2003 19:59:56 GMT  
 new language (it's me again): original idea?

Quote:


> > The point is you have the flexibility to specify the order of
> > execution (you get this anyway), but you can choose to leave the
> > order of execution of parts of a routine (or whatever) upto compiler
> > (or perhaps even the routine itself).

> For functional code the order of evaluation does not matter and
> most (?) languages don't specify in which order subexpressions are
> evaluated.

> But I haven't heard about a concrete implementation of a language
> which executes things in parallel without hints from the programmer.
> Surely there was some research on this.

It depends on the level of parallelism you are talking about. Any compiler
for a VLIW machine will generate ILP code, and compilers for superscalars
will try to arrange code so that any potential ILP can be exploited. Have
a look at Sun's new MAJC architecture, it supports speculative parallel
execution of Java programs by utilising multiple processor cores on a
single chip.

JonB.



Mon, 04 Aug 2003 20:10:35 GMT  
 new language (it's me again): original idea?

Quote:


[...]
> > Have you done any multi-threaded programming in imperative languages?
> > You get the most horrible bugs because of just this.

> It depends, as long as you use proper synchronisation primitives (locks,
> semaphores, critical regions etc) you shouldn't have any problems.

That's unhelpfully like saying that if you don't have any errors, there
won't be any errors!

My experience of multithreaded code in Java (ie mutex-based locking like
you describe) is that thread-related bugs are more difficult to
reproduce, take longer to fix, and are harder to understand than any
other kind of bug.  Sure, if I was perfect I wouldn't get them - but I'm
afraid my code does contain bugs.

(I can well believe other languages are better than this.  The CSP
approach (which I believe is used in Occam) sounds much safer.)

So my argument is that unless there's good reason for having
indeterminate computation in imperative langauges, why bother?  I'd add
that it seems more senseible to use an approach that explicitly isoaltes
state (eg Monads), but the usenet police have forbidden that in thsi
thread...

Andrew



Mon, 04 Aug 2003 20:27:28 GMT  
 
 [ 35 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Call for ideas - a new assembler language ?

2. 'SQL Server Login': Again, again, ...

3. language addition: automatic 'new'

4. language addition: automatic 'new'

5. Scheme vs ML again and again and again and again

6. Scheme vs ML again and again and again and again

7. Original Language Design

8. Posting again : help needed, ideas for 2 player network game + 3d graphics

9. WTB: Iverson's original book on APL

10. Save, but don't change the original creator

11. Wanted to Buy: Original Clipper Summer '87

 

 
Powered by phpBB® Forum Software