February 08, 2007
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
== 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
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
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
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
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
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
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
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
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