Ary Borenszweig wrote in message news:lq199i$1312$1...@digitalmars.com...
I can't seem to learn anything about this language without paying first.
http://en.wikipedia.org/wiki/Forth_(programming_language)
It allows you to edit syntax as you go!
1 2 3 + + . (prints 6)
: 1 2 ;
: 2 3 ;
1 2 3
On Monday, 14 July 2014 at 01:32:38 UTC, Timon Gehr wrote:
On 07/14/2014 03:25 AM, fra wrote:
On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
On 7/13/14, 8:13 AM, fra wrote:
Macros are an aberration that allow code writers to create
code
that is plan impossible to understand
On 13/07/14 17:11, Dicebot wrote:
AST reflection + string mixins can do anything that AST macros can do -
assuming one does not want to allow transparent macros (without explicit
mixin/macro keyword at call site) which is a terrible idea in my opinion
anyway.
I think that is the same thing as
On 13/07/14 17:17, Timon Gehr wrote:
(Just to be sure: I was talking about string mixins, not macros, I
haven't implemented macros.)
Aha, I misunderstood that.
Currently it isn't. It isn't really in a state where I'd like to see it
released. There are some language features still missing,
On Sunday, 13 July 2014 at 20:54:27 UTC, Ary Borenszweig wrote:
AST reflection + string mixins can do anything that AST macros
can do -
assuming one does not want to allow transparent macros
(without explicit
mixin/macro keyword at call site) which is a terrible idea in
my opinion
anyway.
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a matter of
naming your functions properly.
auto subtract(int a, int b){ return a+b; }
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because
operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a
matter of naming your
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because
operator
overloading is still not limited enough
There is no real point in limiting it at all. It is just a
matter of naming your
On 7/14/14, 12:29 PM, Dicebot wrote:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It
On 07/14/2014 05:29 PM, Dicebot wrote:
On Monday, 14 July 2014 at 15:13:21 UTC, Timon Gehr wrote:
On 07/14/2014 11:55 AM, Dicebot wrote:
I must admit D is far from perfect in that regard because operator
overloading is still not limited enough
There is no real point in limiting it at all. It
On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
Making macros look like regular function calls, that you might
not like. For me, it makes the code more readable. Instead of
this:
class Foo
mixin(property :foo)
end
Or this:
class Foo
property!(:foo)
end
You simple write
On Monday, 14 July 2014 at 16:10:59 UTC, Timon Gehr wrote:
Same principle of surprise minimization. Reader expects
arbitrary
actions done by function call.
No way.
?
Reader expects arithmetical semantics
Right, arithmetical semantics, which for built-in '+' can reach
from wrap-around
Dicebot wrote in message news:luounykqutytridry...@forum.dlang.org...
D is decent language in that regard - I am speaking about
imaginary language that does not constraint any semantics and
provides perfect expressive power.
Forth is not an imaginary language.
On Monday, 14 July 2014 at 17:48:12 UTC, Daniel Murphy wrote:
Forth is not an imaginary language.
Ah, Forth, a language so terse that you don't edit files, but
screens. Quite expressive indeed, remember waiting in line behind
some dude hijacking printer for raytracing in postscript... ;)
On Monday, 14 July 2014 at 16:46:08 UTC, Dicebot wrote:
On Monday, 14 July 2014 at 16:10:54 UTC, Ary Borenszweig wrote:
Making macros look like regular function calls, that you might
not like. For me, it makes the code more readable. Instead of
this:
class Foo
mixin(property :foo)
end
Or
On 7/14/14, 2:48 PM, Daniel Murphy wrote:
Dicebot wrote in message news:luounykqutytridry...@forum.dlang.org...
D is decent language in that regard - I am speaking about imaginary
language that does not constraint any semantics and provides perfect
expressive power.
Forth is not an imaginary
On Monday, 14 July 2014 at 18:58:58 UTC, Ary Borenszweig wrote:
I can't seem to learn anything about this language without
paying first.
Not much to learn, it is kinda like stack-based assembly, but
useful knowledge if you want to generate Postscript. GNU appears
to have a free version:
On 2014-07-11 16:14, H. S. Teoh via Digitalmars-d wrote:
auto result = logAndCall!(myFunc, q{1.0 + 2.0/4});
You're passing it as a string.
--
/Jacob Carlborg
On 2014-07-12 01:02, Dicebot wrote:
Whatever is ideal solution, we better focus on something practical that
can be realistically added to the language within current priorities
(stability, minimizing addition of new features, clearing corner cases
etc.)
Funny thing you should mention
On 2014-07-12 01:46, Idan Arye wrote:
I assume read-only reflection means that functions produce ASTs that
are directly embedded into the code(rather than modifying the AST of
existing code) which is the same as with macros.
No, I'm pretty sure he means you can only reflect on the AST. Not
On Friday, 11 July 2014 at 23:46:44 UTC, Idan Arye wrote:
AST(T) toAST(T)(macro(T) expr){
return expr;
}
And I mean something like this:
string takeAST(__ast expr)()
{
return expr.stringof; // need more detailed reflection than
that of course ;)
}
mixin(takeAST!(2 +
On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
On 2014-07-12 01:02, Dicebot wrote:
Whatever is ideal solution, we better focus on something
practical that
can be realistically added to the language within current
priorities
(stability, minimizing addition of new features,
On Friday, 11 July 2014 at 16:44:32 UTC, Ary Borenszweig wrote:
I think D would be much easier to use if it had proper macros.
No need to mess around with q{...}, with string concatenations
for generating code (let the compiler do that) and also to make
the code more readable and easier to
On 07/13/2014 01:13 PM, fra wrote:
...
Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain.
If that is what they want to do, that is what they are going to do.
They don't need macros for that.
Mixins can give you pretty much the
On 07/13/2014 12:45 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 10:19:26 UTC, Jacob Carlborg wrote:
On 2014-07-12 01:02, Dicebot wrote:
Whatever is ideal solution, we better focus on something practical that
can be realistically added to the language within current priorities
(stability,
On Sunday, 13 July 2014 at 12:33:21 UTC, Timon Gehr wrote:
Yes I know and likely would have preferred that approach if we
were
speaking about designing brand new language. But right now we
already
have string mixins
They are not a great liability. They are a simple feature. They
take up
On Friday, 11 July 2014 at 01:35:41 UTC, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a
function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D
On Sunday, 13 July 2014 at 12:55:30 UTC, sigod wrote:
Something like this would be possible if one could get string
representation of a lazy expression:
```
void _logfx(lazy int expr)
{
DebugLog(expr.stringof); // currently it outputs `expr()`
fx(expr);
}
```
lazy expressions are in
On 2014-07-13 14:33, Timon Gehr wrote:
They are not a great liability. They are a simple feature. They take up
less than 200 lines of code in my D frontend implementation, _together_
with template mixins.
Do you have the source for your frontend available somewhere?
--
/Jacob Carlborg
On 07/13/2014 02:44 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 12:33:21 UTC, Timon Gehr wrote:
Yes I know and likely would have preferred that approach if we were
speaking about designing brand new language. But right now we already
have string mixins
They are not a great liability. They
On Sunday, 13 July 2014 at 14:23:07 UTC, Timon Gehr wrote:
I am not saying it is insanely complicated but that it is not
orthogonal
to existing features. ...
I am saying that string mixins are way too simple a feature to
meaningfully block the way for features that are not
orthogonal to
On 07/13/2014 04:09 PM, Jacob Carlborg wrote:
On 2014-07-13 14:33, Timon Gehr wrote:
They are not a great liability. They are a simple feature. They take up
less than 200 lines of code in my D frontend implementation, _together_
with template mixins.
Do you have the source for your frontend
On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
(Just to be sure: I was talking about string mixins, not
macros, I haven't implemented macros.)
Currently it isn't. It isn't really in a state where I'd like
to see it released. There are some language features still
missing, and its
On 07/13/2014 05:24 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 15:17:27 UTC, Timon Gehr wrote:
(Just to be sure: I was talking about string mixins, not macros, I
haven't implemented macros.)
Currently it isn't. It isn't really in a state where I'd like to see
it released. There are some
On 7/13/14, 12:11 PM, Dicebot wrote:
On Sunday, 13 July 2014 at 14:23:07 UTC, Timon Gehr wrote:
I am not saying it is insanely complicated but that it is not orthogonal
to existing features. ...
I am saying that string mixins are way too simple a feature to
meaningfully block the way for
On 7/13/14, 8:13 AM, fra wrote:
On Friday, 11 July 2014 at 16:44:32 UTC, Ary Borenszweig wrote:
I think D would be much easier to use if it had proper macros. No need
to mess around with q{...}, with string concatenations for generating
code (let the compiler do that) and also to make the code
On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
On 7/13/14, 8:13 AM, fra wrote:
Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain. Mixins can
give you pretty much the same amoun of functionality while
imposing sane
On 07/14/2014 03:25 AM, fra wrote:
On Sunday, 13 July 2014 at 20:56:31 UTC, Ary Borenszweig wrote:
On 7/13/14, 8:13 AM, fra wrote:
Macros are an aberration that allow code writers to create code
that is plan impossible to understand and mantain. Mixins can
give you pretty much the same amoun
Delorien:
I have a C macro, which takes an argument, log it and call a
function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
Is a syntax like this acceptable?
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
No, I don't
On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a
function. So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
On 7/11/14, 11:14 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a
function. So, if I had a source code like this:
{
Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
features).
On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
features).
Wouldn't AST reflection be more complex to implementuse than a
macro system? I mean, a macro system is
On 7/11/14, 7:38 PM, Idan Arye wrote:
On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
Full macro system is not needed to implement it, just AST reflection
can do the trick (and has better fit with existing features).
Wouldn't AST reflection be more complex to implementuse than a macro
On Friday, 11 July 2014 at 22:38:36 UTC, Idan Arye wrote:
On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
features).
Wouldn't AST reflection be more complex to
On Friday, 11 July 2014 at 22:42:26 UTC, Ary Borenszweig wrote:
Also, what you want to do with an AST is definitely creating
code. And, in my opinion, it's much easier to create code by
writing it and not by creating the nodes.
Choice is very simple in my opinion. AST macro system overlaps
On Friday, 11 July 2014 at 22:59:10 UTC, Dicebot wrote:
On Friday, 11 July 2014 at 22:38:36 UTC, Idan Arye wrote:
On Friday, 11 July 2014 at 17:00:32 UTC, Dicebot wrote:
Full macro system is not needed to implement it, just AST
reflection can do the trick (and has better fit with existing
Hi,
I have a C macro, which takes an argument, log it and call a
function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
Thank you.
49 matches
Mail list logo
