Re: Cooking up a new language and need suggestions

Cem Karan wrote:
>
> A while ago, as I was trying to help a friend of mine who is just
> learning how to use a computer,


<snip>


> I then tried to tell her a little of how programming
> works, but inside of a few minutes, she stated that that was too
> difficult that there must be an easier way. I was about to start to
> argue with her, when I suddenly realized that she was right; there
> probably was an easier way. And so, I've been spending the past while
> trying to think up how to make programming easier, in the process
> developing ideas for a new language.


Yep. Me too. Well, mine's not a "new" language, so much as a
dialect of an older one. I picked scheme as a starting point,
because it's one of the easiest languages in the world to learn,
and I'm developing an IDE/compiler (it's slow work, because I'm
unfamiliar with C++ and the windows environment) for a dialect
of it which I call "Crystal".


Some of the distinctions between Crystal (if I ever finish this
project) and Scheme are:


graphics, sounds, video, and other multimedia stuff are just
values. If you have a graphic constant in your code, you will
see the image in your source. Putting it on the screen is as
simple as outputting text. Sounds are a speaker icon and checksum
in the visible sourcecode; but when you mouse the icon in the
IDE, you actually hear the sound constant. Or if an expression
returns a sound as a value at the top level, you actually hear
that sound in the read-eval-print loop.


Windows are just values too, and each window is also a
port. System messages become available as input at that port
when the window is opened; values written to that port will
appear in the window. Hide, minimize, resize, and so on are
functions that can be called with a window argument.


Text has properties, such as its font, color, and typeface size.
The font in which a string constant appears in the source code is
the font in which it will be output if written by the program.


I'll be adding a largish library of stuff to work with sounds
and graphics, and other extension data types -- functions which
take them as arguments and return them as function results, for
the most natural possible handling in scheme. You ought to be
able to call "superimpose" on two graphics for example, and get
back a graphic that has one pasted on top of the other.


My basic approach with crystal is that text, as a sequence of
characters, is no longer expressive enough to be the sole form
of source code. Computers can handle a lot of stuff now that
isn't text, and it's about bloody time programmers were allowed
to say what they mean. It should be possible to include,
*Directly* in the code, every kind of value you want to work
with, and treat it the same as every other kind of value.


But there are some pretty serious issues of language and
efficiency that are starting to rear their ugly heads. :-)
I'm going to have to fight to get crystal out with any kind of
good performance and logical (scheme-consistent) structure,
but I think it's a fight that's worth it.


Bear
[In followups, please try and stick to compiler topics. General language
design goes to comp.lang.misc. -John]




--

Return to the comp.compilers page.
Search the comp.compilers archives again.