Re: RAD vs. performance


"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message
news:20060628162332.GA18750@xxxxxxxxxxxxxxxxxxxxxxxxxxx
On Wed, Jun 28, 2006 at 11:45:38PM +1000, cr88192 wrote:

"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message
news:20060628093917.GW18750@xxxxxxxxxxxxxxxxxxxxxxxxxxx

I'm responding to a whole lot of messages all at once here; so if
you're
getting confused about who I'm replying to, it's all my fault. ;-)

ok.
just curious:
there any way/motive to suppress the generating posts as
text-attachments?
responing requires a repetative editing process (or at least with outlook
express...).

I guess Outlook Express has difficulty with PGP signed messages. I've
not signed this message; does that solve the problem? Is anybody else
having problems with this?

yeah, now they look like normal posts.

I thought the semantics we had were for numbers, and ints and floats
are
just hacks we use to get computers to work with them. To me, it seems
that _ideally_, as a programmer, you wouldn't have to worry about
whether your numbers are integers or floats or bignums or rationals or
complex numbers or whatever else.

yes.

the only thing imo is that the more flexible the numbers, the slower the
math, and that some operations only make much sense for certain numeric
types...

It depends on what the compiler can infer and optimize. If the compiler
can infer (or be told) that numbers never exceed the constraints of a
fixnum, it can use fixnums to represent numbers and elide all run time
checks. If some of the numbers might be arbitrary-precission complex
numbers, then either they must always be represented as such, or run
time checks must be made.

yes.

about the only really hairy case I can think of is division, where:
int/int => int|float
which is not so good for static checks.

And not so good for correctness, either. Better would be:

rational / rational => rational

rationals are another type, which are not supported in the cpu and would
likely require an on-heap object (though enough space in references is
left,
eg, if a 12.12 representation was used in-place).

Right. It depends what you want. Floats may be more efficient to work
with, but they may also give you wrong answers.

or more like, inexact answers.
for a lot of uses, one ends up doing some amount of fudging (normalizations,
epsilon clamping, ...).

it is like, the usual rule for vectors: vectors are viewed as equivalent so
long as the error between them is below a certain minimum.

floats are inexact, but, accurate enough...

For many applications, but there are other applications where they
aren't.

so I guess it comes down to whether one can accept inexactness.

if I wanted I could add rationals. then again, it may make sense, as for the
most part I have it distinguish between ints and floats anyways (3 and 3.0
are not necissarily equivalent).

16/9 will give a rational but 16.0/9 gives a float.
hmm...

Really, the difference between static and dynamic typing isn't that
dramatic. The difference is that, for static typing, you reject
programs
when you aren't 100% certain that the types are good, whereas in
dynamic
typing you assume they are until you are 100% sure they aren't (which
you find out at run time). In cases where you are 100% sure the types
are correct at compile time, there needn't be a difference.


well, this is assuming one is using an inference-based static language
(rather than typed declarations based language with a class-based types
model).

this does not hold up so well, eg, between c++ and scheme...

Why do you think it does not apply to languages with explicit typing?

well, mostly because they lead to "mindset" differences (sort of like the:
"object is the variable" vs. "object is referenced by the variable"
concept).

in a language like c, it is well accepted that a function will only accept
what it accepts, and anything else that can will be converted to what it
accepts. likewise with all the variables.

explicit types flow in an "outward-inward" direction, where types are
converted and normalized as needed, and always a consistent type as one
moves inward, wheras implicit and dynamic typing tends to flow in an
"inward-outward" direction, where it is the inner expressions that have the
power to determine types.

I will argue that the distinction is enough to be worth noting.


I considered multi-definitions, but they have not been implemented.

You mean ad-hoc polymorphism?

maybe.

f(x)x*f(x-1);
f(1)1;

I have had this in past languages, but often lacked that much compelling use
(beyond what could be fixed easily enough, eg, with an if expression...).

f(x)if(x>1)x*f(x-1) else 1;


a few more core parts of the language are now implemented.
vectors are now implemented (in a simplistic/incomplete form), but I need to
decide between my old convention (adding some unary operators for some
vector ops) or that of using functions.

|vec, would before give the vector length;
/vec, would give the normalized vector;
....

I am right now more leaning twards my old convention.


objects are now more implemented, using about the same syntax as before.
given the newer compiler behavior, they are implemented differently, so I
made a change to the syntax some.

before I would write:
obj=[x:=3, y:=4];

but now this is also possible:
obj=[x=3, y=4];

note that with this syntax, at creation all expressions are evaluated in
terms of the parent, and all delegates are stated explicitly, eg:

obj=[x=3, y=4, f=fun()(x+y)*z, _parent=self];

z=5;
obj.f(); => 35

note that z is referenced via delegation (this is assuming z was not defined
as a lexical variable).

my last lang also had a syntax that had made delegation implicit, but I have
not re-implemented it (and rarely used it anyways, since the 'dictionary'
syntax often made more sense for what I was doing anyways...).

I guess similar could be done with:

with [_parent=self]
{
int x=3;
int y=4;
f()(x+y)*z;
}

albeit this would require, first reimplementing with, and making the
compiler realize that bindings are being done in the context of the object,
and not any containing function (probably done easy enough by compiling the
statements in a new context).

could reimplement as before, but maybe less work would be to compile the
statements as a block, and adding a new opcode (call_with) or similar (less
funky compiler/vm hacks).

or such...

Regards,

Bob

---
Never underestimate the power of stupid people in large groups.



.

Relevant Pages

  • Re: Why C for operating systems
    ... This kind of modification of the language is something that is useful ... extensions in the compiler. ... That's where Lisp shines: you can easily ... Homoiconicity is when the syntax to write data is ...
    (comp.programming)
  • Re: Compiler and an interpreter
    ... >> Suppose in a source-code file, the 4th line contains the first syntax ... >> error.Can anybody please tell me how the compiler and interpreter will ... Some small unit of the language is an acceptable input. ... Perl does not to my knowledge in any way require the reading of the ...
    (comp.programming)
  • Re: Misplaced parenthesis
    ... The entire purpose of the parser component of a compiler is syntax ... Now the language, accepted by the compiler, is a subset of the ... grammar that describes an superset of the OPL language. ...
    (comp.lang.pascal.delphi.misc)
  • Re: mixing C and assembly
    ... What you're doing here is writing assembly with C syntax. ... a heavily non-standard language extension, ... how the compiler behaves (you don't want the compiler to use the stack ... high-level language as fast as possible. ...
    (comp.arch.embedded)
  • Re: RAD vs. performance
    ... It depends on what the compiler can infer and optimize. ... rationals are another type, which are not supported in the cpu and would ... The difference is that, for static typing, you reject programs ... (rather than typed declarations based language with a class-based types ...
    (comp.lang.misc)