Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » My new programming language.

This thread is locked; no one can reply to it. rss feed Print
My new programming language.
SiegeLord
Member #7,827
October 2006
avatar

Or, to rephrase, will you support CTFE?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

anonymous
Member #8025
November 2006

bamccaig said:

// In C++, not allowed:
const Color RED = Color(255, 0, 0);

You may post this as a separate question, but you most certainly can do it:

class Color
{
    unsigned char r, g, b;
public:
    Color(unsigned char r, unsigned char g, unsigned char b): r(r), g(g), b(b) {}
};

int main()
{
    const Color RED = Color(255, 0, 0); //initialization, not assignment

}

You can also do it for constant class members (initialization list).

bamccaig
Member #7,536
July 2006
avatar

axilmar
Member #1,204
April 2001

SiegeLord said:

I was objecting to the const being on the right side of the colon, since I think that constness of a variable has nothing to do with the type, and therefore should be on the left side of the colon.

Actually, this language will have const types, not const variables. In my opinion, constness belongs to types.

I am allowing the 'const var x = y' declaration as a shortcut (and I actually changed the grammar to have an obligatory 'var' after 'const', for consistency reasons).

bamccaig said:

Do constant variables have to refer to a literal or existing constant expression (i.e., another constant variable) or can any value be used for a constant variable?

Any value can be used for a constant variable. The syntax

var x = y;

simply constructs value 'y' with label 'x' attached to it.

SiegeLord said:

Or, to rephrase, will you support CTFE?

No. Constants are computed at run-time. The optimizer might compute them at compile time, but the values are not to be available at compile time.

The orthogonal approach to compile-time computations is to use macros. I have some ideas about that, but I would like to leave this complicated topic at the end.

Arthur Kalliokoski
Second in Command
February 2005
avatar

axilmar said:

The above is also valid even if you do not use threads, because modern CPUs may thread your computations.

I thought a single threaded program only ran on a single thread, although it may move from core to core after task switches. I've never noticed a math speed up for single threaded, although two cores would have 50% load each instead of one core having 100%.

They all watch too much MSNBC... they get ideas.

axilmar
Member #1,204
April 2001

I thought a single threaded program only ran on a single thread, although it may move from core to core after task switches. I've never noticed a math speed up for single threaded, although two cores would have 50% load each instead of one core having 100%.

I meant out-of-order execution.

SiegeLord
Member #7,827
October 2006
avatar

axilmar said:

const var x = y

Why not var x : const = y then? Shortcuts are nice, but they should be done in a fashion consistent with the rest of the language. If you are going to allow that syntax, why not allow the int var x = y too?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

BAF
Member #2,981
December 2002
avatar

I still say pointer arithmetic is unnecessary when replaced with cleaner conventions. As are unions. My whole point in questioning them was the quote that these features would enable Allegro to be written directly in the new language, without doing anything in C. I'm claiming that with a cleaner/higher level language (which I thought was what this was) you could still write Allegro in said language without shitty pointer arithmetic, unions, etc.

GullRaDriel
Member #3,861
September 2003
avatar

And lose all the portability/compatibility.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

axilmar
Member #1,204
April 2001

SiegeLord said:

Why not var x : const = y then? Shortcuts are nice, but they should be done in a fashion consistent with the rest of the language. If you are going to allow that syntax, why not allow the int var x = y too?

1) const is a derived type, int is not.

2) you get const for free in the grammar, due to attribute syntax. No such lack for types. Putting the type before the var name prohibits a context free grammar.

3) 'var x : const = y' is a nice idea and I will adopt it. I will remove the 'const var x = y'.

BAF said:

I still say pointer arithmetic is unnecessary when replaced with cleaner conventions. As are unions. My whole point in questioning them was the quote that these features would enable Allegro to be written directly in the new language, without doing anything in C. I'm claiming that with a cleaner/higher level language (which I thought was what this was) you could still write Allegro in said language without shitty pointer arithmetic, unions, etc.

You are talking about two different things: 1) a higher level interface to Allegro5, 2) a direct interface to Allegro5. The unsafe features of this language allow #2; without those features, it would not be possible to do #2. You can always do #1 and avoid the unsafe features.

For those that are interested, I've written a large post in the blog about classes.

BAF
Member #2,981
December 2002
avatar

I'm not talking about Allegro5 in C form. You were claiming these features were necessary to implement Allegro5 in your language (unless I read it wrong, it sounded to me like you were speaking more in theory, discussing the it being possible to write Allegro5 itself in your language). I'm claiming you only need those features to interface to other crap that uses them, but to re-implement, they can be replaced with much cleaner alternatives.

Thomas Fjellstrom
Member #476
June 2000
avatar

BAF said:

but to re-implement, they can be replaced with much cleaner alternatives.

I'll bet allegro's "hacky" event implementation beats the pants off of anything you can come up with in C++/C# performance wise. Its also thread safe, so keep that in mind.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

axilmar
Member #1,204
April 2001

BAF said:

I'm claiming you only need those features to interface to other crap that uses them, but to re-implement, they can be replaced with much cleaner alternatives.

Certainly. But C is the Lingua Franca of computers. It's bad, but there is nothing we can do about it...

BAF
Member #2,981
December 2002
avatar

So it seems I just misunderstood what you were saying. :P

I'll bet allegro's "hacky" event implementation beats the pants off of anything you can come up with in C++/C# performance wise. Its also thread safe, so keep that in mind.

Maybe so, but it wouldn't matter too much. Plain old events in C# (language level feature) would be plenty fast enough. I'll gladly trade whatever performance may be lost for the higher level language - in most cases, the performance doesn't make a huge difference anyhow.

Thomas Fjellstrom
Member #476
June 2000
avatar

BAF said:

Plain old events in C# (language level feature) would be plenty fast enough.

Lets hope so. People thought the same thing about GTK/GDK's event stuff for a long time too. Turns out it really isn't. horribly slow. When Qt got support for the gtk event loop, all of a sudden apps that ran fine before slowed down, and occasionally slow enough that it actually caused redrawing to slow down.

Quote:

in most cases, the performance doesn't make a huge difference anyhow.

In most cases, the lack of performance causes otherwise useful things to just not be done, because it would either be slow, or impossible.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

axilmar
Member #1,204
April 2001

Let's also not forget that there is a new generation of not-so-powerful computers in the market that are cheap enough to be massively bought. Doing interesting software on them makes every cycle count.

GullRaDriel
Member #3,861
September 2003
avatar

Whatever the computer power is, do what you can and much to save energy.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

bamccaig
Member #7,536
July 2006
avatar

axilmar
Member #1,204
April 2001

bamccaig said:

The blog is...gone!?!? :o

Yes...not much interest in it to justify the effort.

GullRaDriel
Member #3,861
September 2003
avatar

Blog is gooooooooooooooooooooooone (on David Guetta's Love is gone ^^)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Vanneto
Member #8,643
May 2007

axilmar said:

Yes...not much interest in it to justify the effort.

So, is the language also cancelled?

In capitalist America bank robs you.

axilmar
Member #1,204
April 2001

Vanneto said:

So, is the language also cancelled?

Yes.

Jonatan Hedborg
Member #4,886
July 2004
avatar

Did you cancel your project because your new, unfinished, language did not gather enough users? ???

BAF
Member #2,981
December 2002
avatar

He cancelled it because he realized he can just use C#. ;D

axilmar
Member #1,204
April 2001

I canceled it because of lack of interest.



Go to: