Re: Ideal computer language from scratch?


sevagK wrote:
Dragontamer wrote:

1. First order Functions; aka, functions as data.
2. Defining functions as combinations of data
3. Currying
4. Lazy data structures (such as an infinitly long list)
5. Guarentee a lack of side effects in a specific function
6. Creating a function during runtime

#5 shouldn't even be on the list, that's a discipline at the
programmers discretion, for example, one need only use local
variables/registers.
The other ones, most (if not all) can be done with assembly with
variances in cost to implement, but the question would be why? Such
things have little use in assembly programming and specialized tools
can be used on rare occasions that the need pops up.

Yeah, in hindsight, I agree.

[snip]

1. Haskell basically only deals with functions. All data is concieved
as a function
that only returns one value.

From what I gather, you can have functions return sets of data as well.
Here is one I learned going through a tutorial:

roots :: (Float, Float, Float) -> (Float, Float)
roots (a,b,c) = if d < 0 then error "No" else (x1, x2) where
x1 = e + sqrt d / (2 * a)
x2 = e - sqrt d / (2 * a)
d = b * b - 4 * a * c
e = - b / (2*a)

Takes 3 float as input, outputs 2 float, nicely formatted in bracktes
and comma.
Like I mentioned in another post... it makes a nice calculator which
comes in handy in other aspects of my "self teaching" ambitions. I
could easily do these things in assembly but the cost of setting up the
FPU and breaking down the equasion into instructions is considerably
higher in assembly, especially considering that "roots" is one of the
easier ones to implement!

(float, float, float) is a tuple. That is, a coordinate; a point on an
imaginary
3 dimentional map.

You conceptualize this as a mapping of 3-dimentions to 2-dimentions.

But this "data" is really just a single point. If you get my drift. ()
defines
a tuple, so it is single data.

A bit of a stretch i guess :)

However, if I needed a routine to calculate millions of quadratic
roots, I would certainly take the time ane implement it in assembly.

Of course; efficiency is assembly's greatest asset.

But I brought up Haskell because it spurs a different way of thinking
about programming; one I feel isn't represented well in Assembly
language. I don't necessarily think Haskell is "better" necessarily.

2. The foldr example in my last post was Haskell code.

3. Again, the concept in my last post was a currying example in
Haskell.

4. fibs = 1 : 1 : zipWith (+) fibs (tail fibs)


This is where my interest in functional languages wanes. Seeing the
above, I'm left with the impression of What!? Looking up the source of
zipWith I get even more confused. After reading 2 tutorials on the
subject and glancing over a volume on the language, I'm left with a
sence of bewilderment that I never experienced with assembly. To me,
the learning curve required to make Haskell work wonders for me is just
not worth it.

As said, different way of thinking about a problem; entirely.

zipWith takes a function (in this case, +) and applies it to 2 lists,
fibs and (tail fibs).

fibs can be seen as the beginning of the list.
tail fibs can be seen as a pointer to the 2nd element of the list.

So the code expands to:

1 : 1 : fib[0] + fib[1] : fib[1] + fib[2] : fib[2] + fib [3] etc. etc.

Lazy evaluation allows this to happen; zipWith doesn't do it instantly,
it is
"reserved" for later.

6. Haskell can do this with lambda function. Ditto with Scheme and
Lisp, and python.
It *defines* a new function; during runtime. So you can read in a file
for example, and
create a new function based on the file's inputs, or the user's input,
or data from
a network.

The code for the creation of these new functions must be defined. I'm
thinking the main design use for this is argument overloading. The
code still has to be there. With imperetive languages, you have to
write all the supported 'function' types in advance. Which isn't a big
problem, you know what kind of data your program is expected to process
during the design phase anyways.

Yes, it is defined. But in say, Scheme interpreters where this is
possible,
it is defined as first creating a Scheme function, and then translating
it to
assembly as it executes. Which fails the beginning of my challenge
(don't
build a language to solve this problem)

I've read on the concept of "thunks" which are somewhat similar to what
you describe, but I have yet to encounter anything that the use of
thunks would simplify for code that I write. However, I will keep it
in mind as another 'tool' that may one day come in handy.

Thunks make cofunctions easy. Expand it to continuations (save the
entire
call stack and not just the stack upto ebp) and you can create
throw/catch
statements with ease.

Generators are also reletivly easy to make using thunks/continuations,
basically a function that returns the "next" value; kinda like an
iterator.

--Dragontamer

.

Relevant Pages

  • Re: soc.culture.celtic FAQ
    ... The Celts ... Celtic language mailing lists ... How do I identify which Celtic language this is? ... The Irish Penitentials: Their Religious and Social ...
    (soc.culture.celtic)
  • Re: soc.culture.celtic FAQ
    ... The Celts ... Celtic language mailing lists ... How do I identify which Celtic language this is? ... The Irish Penitentials: Their Religious and Social ...
    (soc.culture.celtic)
  • Re: How come Ada isnt more popular?
    ... are praising is, because what about trees of strings, trees of lists etc. ... A language with a Hinldey-Milner type system ... container varies, the element does not. ...
    (comp.lang.ada)
  • Re: soc.culture.celtic FAQ
    ... This FAQ was first launched May 1994. ... The Celts ... Celtic language mailing lists ... How do I identify which Celtic language this is? ...
    (soc.culture.celtic)
  • Re: Lisp for the C21
    ... Language design is not about necessity. ... and the need for variadic functions goes ... Every functional language I remember has lists as matter of course, ... OCaml can do almost the same thing as Lisp does with &rest and that is ...
    (comp.lang.functional)
Loading