View mode: basic / threaded / horizontal-split · Log in · Help
February 08, 2007
Re: DMD 1.005 release
Andreas Kochenburger wrote:
> Kevin Bealer wrote:
> 
>> Charles D Hixson wrote:
>> But the central feature of FORTH is that the compiler and runtime can 
>> be made mind-bogglingly small.  I think the run time speed for a naive 
>> interpretation is probably somewhere between C and interpreted bytecode.
>>
>>  From this page about tiny4th: http://www.seanet.com/~karllunt/tiny4th
>>
>> "The run-time engine takes up less than 1K of code space and the 
>> p-codes are so dense that you can get a lot of robot functionality in 
>> just 2K."
> 
> 
> Before someone thinks, Forth is only a play-thing, see 
> http://www.forth.com/
> 
> There are also excellent freeware versions around, f.ex.
> http://win32forth.sourceforge.net/
> 
> There is even ans ANS / ISO standard for the language.
> 
> Andreas


Yeah, Forth is an incredibly powerful language
February 08, 2007
Re: DMD 1.005 release
== Quote from Walter Bright (newshound@digitalmars.com)'s article
> Serg Kovrov wrote:
> > Ary Manzana wrote:
> >> But... I'm wondering which are the evil uses of it. For me it's now
> >> almost impossible not to program with an IDE (big projects, I mean).
> >> At least in Java. Maybe compile time stuff will make it such that an
> >> IDE won't be needed anymore. But it's very hard for me to see that
> >> happening.
> >
> > I believe by 'evil use', Walter meant evil use of mixins, not IDE's.
> > Isn't he?
> >
> Yes. IDEs aren't evil.

What about:

http://vigor.sourceforge.net/

(*but maybe he doesn't count as an IDE.)

Kevin
February 08, 2007
Re: DMD 1.005 release
On Thu, 08 Feb 2007 18:57:24 +0100, Andreas Kochenburger wrote:

> Kevin Bealer wrote:

> Before someone thinks, Forth is only a play-thing, see http://www.forth.com/
> 
> There are also excellent freeware versions around, f.ex.
> http://win32forth.sourceforge.net/
> 
> There is even ans ANS / ISO standard for the language.

Forth was the first programming language that felt a mystical connection
to. I still love its simplicity/complexity dichotomy. I haven't really
touched in years though so I may just go and spend some time with that old
friend again.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
9/02/2007 10:31:43 AM
February 09, 2007
Re: DMD 1.005 release
Yauheni Akhotnikau wrote:
> On Thu, 08 Feb 2007 10:08:29 +0300, Walter Bright 
> <newshound@digitalmars.com> wrote:
> 
>> Yauheni Akhotnikau wrote:
>>> I'm use Ruby a lot and much metaprogramming things done via creating 
>>> strings with Ruby code and evaluating it by various 'eval' methods. 
>>> It is very simple method -- easy in writting, debugging and testing. 
>>> And there isn't two different Ruby -- only one language.
>>
>> That's possible because Ruby is interpreted - its compilation 
>> environment is also the execution environment.
>>
>> But D is a statically compiled language, so there's a distinction 
>> between a compile time variable, and a runtime variable.
> 
> Yes, I undertand that. But that is my point: in Ruby there are three steps:
> 1) use ordinal Ruby code to produce string with another ordinal Ruby code;
> 2) translation of string with ordinal Ruby code into bytecode;
> 3) run of bytecode.
> 
> In D we now have steps 2) and 3) implemented: step 2) is a compilation 
> phase. The question is: how to perform step 1)?
> 
> If it is necessary to use special constructs to build strings with 
> ordinal D code then I will prefer to use pre-compile-time generation 
> with help of external tools.
> 
> For example, in last four years I have used home-made serialization 
> framework for C++. It requires special description of serializable type 
> in special Data Definition Language, like this:
> 
> {type {extensible}    handshake_t
>   {attr    m_version {of oess_1::uint_t}}
>   {attr    m_client_id {of std::string}}
> 
>   {extension
>     {attr  m_signature
>        {of signature_setup_t}
>        {default {c++ signature_setup_t()}}
>     }
>     {attr  m_compression
>        {of compression_setup_t}
>        {default {c++ compression_setup_t()}}
>     }
> 
>     {extension
>        {attr m_traits
>           {stl-map {key oess_1::int_t}}
>           {of handshake_trait_shptr_t}
>           {default {c++ std::map< int, handshake_trait_shptr_t >()}
>               {present_if {c++ m_traits.size()}}
>           }
>        }
>     }
>   }
> }
> 
> The library for parsing such s-expression is about 7K lines in C++ and 
> 2.5K lines in Ruby. Comparable size it will have in D. But, if I want to 
> use such DDL as DSL in mixin expression I must write two version of 
> s-expression parsing -- for run-time and compile-time :(
> 
> But if I can use ordinal D code at compile time then the situation is 
> much better.
> 
> --Regards,
> Yauheni Akhotnikau

On the note of serialization I think you could be able to write 
something like this:

mixin(serialize(
"
	class A
	{
		...
		serialize(10) int x; //(10 = default)
		serialize B y;
		int z; //Not serialized
	}
"
));

The serialize would pickup the serialize attributes and re-arrange the 
code however it wanted (ie strip the serialize and put in a serialize 
function)

You probably could do it now, however it will be much easier when a 
method of writing functions like serialize is invented.

-Joel
February 09, 2007
Re: DMD 1.005 release
On Fri, 09 Feb 2007 20:13:14 +0300, janderson <askme@me.com> wrote:

> On the note of serialization I think you could be able to write  
> something like this:
>
> mixin(serialize(
> "
> 	class A
> 	{
> 		...
> 		serialize(10) int x; //(10 = default)
> 		serialize B y;
> 		int z; //Not serialized
> 	}
> "
> ));
>
> The serialize would pickup the serialize attributes and re-arrange the  
> code however it wanted (ie strip the serialize and put in a serialize  
> function)
>
> You probably could do it now, however it will be much easier when a  
> method of writing functions like serialize is invented.

This is not my case. It is necessary for me to use port existing framework  
to D and use existing DDL-files for serializabe types -- it is necessary  
for interoperability between existing C++ applications and future D  
applications.

There are the following steps in the current scheme for C++:
* a special macros must be used in declaration of serializable type (this  
macros hides some declarations of special methods);
* a DDL-file must be written with description of serializable types, its  
attributes and additional information;
* the DDL-file must be processed by special utility which produced file  
with implementation of serialization/deserialization method (those  
declarations are hid by the special macros);
* the generated file included into C++ file with serializable type  
implementation by #include.

DDL file is used to provide possibility to describe serialization of type  
from different languages (C++, Java, D). So it cannot be replaced by some  
unique for D DSL.

Before D 1.005 I had want to generate module with template which contains  
serialization/deserialization code and use ordinal mixin expression to  
mixin that code in D class. D 1.005 makes things more simple -- the result  
of generation can be included into D class by new mixin expression. And if  
future versions make possible to include into D class DDL file itself --  
it will be great! Something like:

class Handshake : Serializable
{
  ... // declarations of attributes and methods.
  mixin( DDLProcessor( import( 'handshake.ddl' ) ) );
}

-- 
Regards,
Yauheni Akhotnikau
February 09, 2007
Re: DMD 1.005 release
Andreas Kochenburger wrote:
> Kevin Bealer wrote:
>> Charles D Hixson wrote:
>> But the central feature of FORTH is that the compiler and runtime can 
>> be made mind-bogglingly small.  I think the run time speed for a naive 
>> interpretation is probably somewhere between C and interpreted bytecode.
>>
>>  From this page about tiny4th: http://www.seanet.com/~karllunt/tiny4th
>>
>> "The run-time engine takes up less than 1K of code space and the 
>> p-codes are so dense that you can get a lot of robot functionality in 
>> just 2K."
> 
> Before someone thinks, Forth is only a play-thing, see 
> http://www.forth.com/

There's an extra comma in there that pretty much changes the meaning of 
the sentence :o).

Andrei
February 09, 2007
Re: DMD 1.005 release
On Fri, 09 Feb 2007 12:12:24 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

> Andreas Kochenburger wrote:
>> Kevin Bealer wrote:
>>> Charles D Hixson wrote:
>>> But the central feature of FORTH is that the compiler and runtime can 
>>> be made mind-bogglingly small.  I think the run time speed for a naive 
>>> interpretation is probably somewhere between C and interpreted bytecode.
>>>
>>>  From this page about tiny4th: http://www.seanet.com/~karllunt/tiny4th
>>>
>>> "The run-time engine takes up less than 1K of code space and the 
>>> p-codes are so dense that you can get a lot of robot functionality in 
>>> just 2K."
>> 
>> Before someone thinks, Forth is only a play-thing, see 
>> http://www.forth.com/
> 
> There's an extra comma in there that pretty much changes the meaning of 
> the sentence :o).
> 
> Andrei


Funny!

:D

-JJR
February 09, 2007
Re: DMD 1.005 release
Andreas Kochenburger wrote:
> Kevin Bealer wrote:
>> Charles D Hixson wrote:
>> But the central feature of FORTH is that the compiler and runtime can 
>> be made mind-bogglingly small.  I think the run time speed for a naive 
>> interpretation is probably somewhere between C and interpreted bytecode.
>>
>>  From this page about tiny4th: http://www.seanet.com/~karllunt/tiny4th
>>
>> "The run-time engine takes up less than 1K of code space and the 
>> p-codes are so dense that you can get a lot of robot functionality in 
>> just 2K."
> 
> Before someone thinks, Forth is only a play-thing, see 
> http://www.forth.com/
> 
> There are also excellent freeware versions around, f.ex.
> http://win32forth.sourceforge.net/
> 
> There is even ans ANS / ISO standard for the language.
> 
> Andreas

I wouldn't have minded writing that, but there was a mistake 
in editing.
>> But the central feature of FORTH is that the compiler and 
>> runtime can be made mind-bogglingly small.  I think the run
>> time speed for a naive interpretation is probably somewhere
>> between C and interpreted bytecode.
etc. was written by Kevin Bealer.

Also, I'm not that impressed by SwiftForth (except the price 
they charge, THAT'S impressive).  OTOH, I'm running Linux, so 
I can only judge them by their web pages.  I tend to think of 
them as being rather like Allegro Lisp:  Enormously more 
expensive than the competition, and only marginally better. 
That said, I don't really have any evidence.  Were I to select 
a Forth to use I'm probably pick gforth or bigforth (+ 
Minos?).  Every once in awhile I think of going back to 
it...but I've lost the books I once had on it.  I've lost, 
sold, given away, or discarded my copies of Forth Dimensions, 
and it would really be a great deal of effort to get as 
familiar with it as I once was.  So I don't.

Neon, though, was impressive.  I think there's a version calls 
MOPS or mops or some such still extant, but I don't know how 
complete it is, and last I checked it only ran on Mac pre-OSX. 
 (I trust that's no longer true...if not, it's history.)
February 10, 2007
Re: DMD 1.005 release
janderson wrote:
> Yauheni Akhotnikau wrote:
>> On Thu, 08 Feb 2007 10:08:29 +0300, Walter Bright 
>> <newshound@digitalmars.com> wrote:
>>
>>> Yauheni Akhotnikau wrote:
>>>> I'm use Ruby a lot and much metaprogramming things done via creating 
>>>> strings with Ruby code and evaluating it by various 'eval' methods. 
>>>> It is very simple method -- easy in writting, debugging and testing. 
>>>> And there isn't two different Ruby -- only one language.
>>>
>>> That's possible because Ruby is interpreted - its compilation 
>>> environment is also the execution environment.
>>>
>>> But D is a statically compiled language, so there's a distinction 
>>> between a compile time variable, and a runtime variable.
>>
>> Yes, I undertand that. But that is my point: in Ruby there are three 
>> steps:
>> 1) use ordinal Ruby code to produce string with another ordinal Ruby 
>> code;
>> 2) translation of string with ordinal Ruby code into bytecode;
>> 3) run of bytecode.
>>
>> In D we now have steps 2) and 3) implemented: step 2) is a compilation 
>> phase. The question is: how to perform step 1)?
>>
>> If it is necessary to use special constructs to build strings with 
>> ordinal D code then I will prefer to use pre-compile-time generation 
>> with help of external tools.
>>
>> For example, in last four years I have used home-made serialization 
>> framework for C++. It requires special description of serializable 
>> type in special Data Definition Language, like this:
>>
>> {type {extensible}    handshake_t
>>   {attr    m_version {of oess_1::uint_t}}
>>   {attr    m_client_id {of std::string}}
>>
>>   {extension
>>     {attr  m_signature
>>        {of signature_setup_t}
>>        {default {c++ signature_setup_t()}}
>>     }
>>     {attr  m_compression
>>        {of compression_setup_t}
>>        {default {c++ compression_setup_t()}}
>>     }
>>
>>     {extension
>>        {attr m_traits
>>           {stl-map {key oess_1::int_t}}
>>           {of handshake_trait_shptr_t}
>>           {default {c++ std::map< int, handshake_trait_shptr_t >()}
>>               {present_if {c++ m_traits.size()}}
>>           }
>>        }
>>     }
>>   }
>> }
>>
>> The library for parsing such s-expression is about 7K lines in C++ and 
>> 2.5K lines in Ruby. Comparable size it will have in D. But, if I want 
>> to use such DDL as DSL in mixin expression I must write two version of 
>> s-expression parsing -- for run-time and compile-time :(
>>
>> But if I can use ordinal D code at compile time then the situation is 
>> much better.
>>
>> --Regards,
>> Yauheni Akhotnikau
> 
> On the note of serialization I think you could be able to write 
> something like this:
> 
> mixin(serialize(
> "
>     class A
>     {
>         ...
>         serialize(10) int x; //(10 = default)
>         serialize B y;
>         int z; //Not serialized
>     }
> "
> ));
> 
> The serialize would pickup the serialize attributes and re-arrange the 
> code however it wanted (ie strip the serialize and put in a serialize 
> function)
> 
> You probably could do it now, however it will be much easier when a 
> method of writing functions like serialize is invented.

Probably an easier way to go would be:

class A
{
  ...
  int x;
  B y;
  int z;
}

mixin(serialize!(A, "x=10, y"));

This way you leave to the compiler the task of parsing the class, and 
you only deal with the annotations. If you prefer to not centralize them 
(although for serialization it's probably better), you can write:

class A
{
  ...
  mixin(serialize!(int, x, 10));
  mixin(serialize!(B, y));
  int z;
}

Again, you let the compiler to the heavylifting and you limit your 
annotation to the smallest notational unit.


Andrei
February 10, 2007
Re: DMD 1.005 release
Andrei Alexandrescu (See Website For Email) wrote:
> janderson wrote:
>> Yauheni Akhotnikau wrote:
>>> On Thu, 08 Feb 2007 10:08:29 +0300, Walter Bright 
>>> <newshound@digitalmars.com> wrote:
>>>
> 
> Probably an easier way to go would be:
> 
> class A
> {
>   ...
>   int x;
>   B y;
>   int z;
> }
> 
> mixin(serialize!(A, "x=10, y"));

I'm not sure I'd need a mixin for this.

> 
> This way you leave to the compiler the task of parsing the class, and 
> you only deal with the annotations. If you prefer to not centralize them 
> (although for serialization it's probably better), you can write:
> 
> class A
> {
>   ...
>   mixin(serialize!(int, x, 10));
>   mixin(serialize!(B, y));
>   int z;
> }
> 
> Again, you let the compiler to the heavylifting and you limit your 
> annotation to the smallest notational unit.
> 
> 
> Andrei

Some good points, if your going for optimizing the compiler.  I was 
going for cleanest syntax.

-Joel
11 12 13 14 15 16 17 18 19
Top | Discussion index | About this forum | D home