Doe jij eens zoeken op LLVM en prototype in dit topic
Ik zou eerder geneigd zijn om over "een lint/tape" te spreken dan "byte arrays"
. Brainfuck kan met elke taal geimplementeerd worden die turing complete is, omdat het zelf turing complete is, wat ik ook op m'n blog heb staan ;-) .
[ Voor 47% gewijzigd door prototype op 08-11-2008 23:56 ]
. Dit betekent dus in eerste instantie een hybride strong- en weaktyped dynamische taal: typehinten zoals dat in PHP b.v. mogelijk is zal ook hier toegestaan moeten zijn waarbij we dan zelfs nog statische optimalisaties zouden kunnen doen. Je zou het echte doel dan ook misschien kunnen beschouwen als PHP opnieuw ontwerpen zonder rekening te hoeven houden met backwards compatibility en in dit geval dus ook de inconsistenties weg kunnen halen. Achterlijke dingen zoals bij lambda's nog aan moeten geven aan wat voor scope hij moet binden moeten daarbij ook "oprotten" ;-)1
2
| and := (a,b) => {a? {b? true : false} : false};
infix 2 left _&&_ => and; |
[ Voor 14% gewijzigd door link0007 op 29-03-2009 16:09 ]
IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Aangezien alles een object zal worden, kun je de infix operator die jij hier voorstelt gewoon zien als een methode die je aanroept op 't object aan de linkerkant van jouw "infix operator". Als argument krijgt het dan het "rechtergedeelte". Hier zou nog eventueel syntactisch suiker voor geboden kunnen worden, e.g. voo rmethoden die aangeduidt worden als zijnde operatoren, is het toegestaan dan om de record notation dot en eventueel de haakjes weg te laten. Moeten we alleen nog even heel goed over nadenken of dat wenselijk is. Verder hoef je je geen zorgen te maken over evaluatie van dit soort expressies, dat zal gewoon shortcircuited gebruiken by default.:
hoe dynamisch word de taal trouwens? Bij sommige talen kan je je eigen infix operators toevoegen, wat ik echt een immens handige feature vind:
code:
and := (a,b) => {a? {b? true : false} : false}; infix 2 left _&&_ => and;
Geweldige toevoeging voor een taal IMO
Zullen vast nog wel meer talen zijn die dit bieden, maar ik ben het nog niet vaak tegen gekomen
Ze zijn namelijk zo ambigu als de pest als je nog niet weet of een identifier een type aangeeft.[ Voor 15% gewijzigd door .oisyn op 29-03-2009 22:08 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Is inderdaad buitengewoon interessante materie
.
Quelle chimère est-ce donc que l'homme? Quelle nouveauté, quel monstre, quel chaos, quel sujet de contradiction, quel prodige!
FWIW, in Java werkt het zo::
Ondersteun je de bekende cast expressions? En zo ja, hoe?
1
2
3
| CastExpression:
(PrimitiveType Dimsopt) UnaryExpression
(ReferenceType) UnaryExpressionNotPlusMinus |
Volgens beiden is (a)+b alleen een cast als a een primitive/predefined type is. Dat lijkt mij ook de enige mooie oplossing voor een dynamische taal: het is goed gedefinieerd en je hoeft niet at runtime nog eens te kijken wat de bedoeling is...
. Ik ben momenteel aan het spelen met Coco/R, daarmee kun je custom predicates voor productieregels schrijven (die bijvoorbeeld de tokenstream uitlezen om te kijken wat er komen gaat), waardoor hij feitelijk LL(inf) wordt ipv de LL(1) die hij normaal is. M'n huidige implementatie kijkt of er alleen tokens voorkomen die in een type mogen zitten, maar dat is niet genoeg - dan zal hij een expressie als (a, b)+c ook als cast zien. Wat ik nu probeer te doen is de parser iets aan te passen zodat hij simpelweg probeert of het gedeelte tussen haakjes is te parsen als type en zo niet te backtracken (wat het effectief een GLL parser maakt).
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Als je werkt met list of successses, dan kan je op sommige punten tijdens het parsen wat ambiguiteit tegengaan (denk bijv. aan de problemen in LR(k) met shift/reduce conflicten). Je houdt in feite gewoon alle mogelijke parses tot nu toe bij en soms vallen er een paar mogelijkheden af en soms komen er paar mogelijkheden erbij.
Het is gewoon gaaf in Haskell vanwege de lichte syntax om dingen aan elkaar te knopen.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik ben nog niet zo bekend met generalized parsers, maar ik wel o.a. nog Scannerless Generalized-LR Parsing lezen.
Vieze dubbelposter:
Kunnen we niet beter gewoon eerst een eigen parser generator maken?
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Parse error at line 1:
Vieze dubbelposter
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| // wat parser support code
bool IsCastExpression()
{
TryParse tryer(this);
CastExpression();
return tryer;
}
// in de grammer definition
Expression
= AddExpression
.
AddExpression
= AddTerm { "+" AddTerm }
.
AddTerm
= "+" AddTerm
| CastTerm
.
CastExpression
= "(" Type ")" CastTerm
.
CastTerm
= IF(IsCastExpression()) CastExpression
| "(" Expression ")"
| Literal
.
Literal
= ident
| number
| string
. |
[ Voor 113% gewijzigd door .oisyn op 31-03-2009 02:59 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Kijk eens een keertje naar ASF+SDF.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
Ik heb een klein beetje naar SDF gekeken, maar dat was omdat ik bezig was met Stratego/XT voor een practicum Program Transformation & Generation.:
[...]
Kijk eens een keertje naar ASF+SDF.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart
Je schetst hier precies wat ik niet uitdrukte
.Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart
Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.
Ja en daar haal ik wel een 2 aanleidingen uit::
Heb je het begin van dit afgeplitste topic wel gelezen
Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart
Eens
Een nieuwe taal zou impliciet parallel moeten zijn met oog op de volgende generatie hardware. Hoewel dat natuurlijk geen nieuw concept is, want daar is al behoorlijk wat onderzoek naar gedaan en er bestaan ook al een aantal van dat soort talen. Intel komt nu al met de "parallel studio", nvidia en amd etc met OpenCL; keer op keer als ik bij conferenties ben hoor ik het: parallel is de toekomst, bereid je er op voor, of je nou wilt of niet, het komt eraan. Als een algoritme niet schaalt naar meerdere processoren dan is het niet relevant. Dat gaat ook voor talen gebeuren. Handmatig parallel programmeren is te moeilijk. Dat is bij uitstek iets dat een compiler/taal op zou moeten kunnen lossen. Ik zou dus niet blind functionaliteit toe gaan voegen aan een nieuwe taal, maar eerst een kern opzetten en dan bij elke nieuwe functionaliteit vragen of het past bij het ontwerp, en of het wel echt nuttig is. iets van extended blahblah normal form Weet wel wat het is hehe )
[ Voor 4% gewijzigd door Zoijar op 31-03-2009 13:01 ]
Elke keer 1 keer de betekenis erbij zetten terwijl vrijwel iedereen hier op het forum, behalve jij blijkbaar, weet wat ermee bedoeld wordt? Afkortingen zijn juist handig. Het verminderd ruis zodat je je meer kunt concentreren op de daadwerkelijke inhoud.
[ Voor 4% gewijzigd door .oisyn op 31-03-2009 14:04 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Moeten dergelijke afkortingen niet met kleine letters?:
[...]
Dus, samenvattend, IIRC kent zo'n beetje elke GoTer wel al die afkortingen en AFAIK heeft zelden daar iemand problemen mee, dus IMHO ben je gewoon een beetje aan het zuren, ITT de anderen in de topic die IIG wel een relevante bijdrage leveren DMV constructieve posts MBV afkortingen ICM bekende termen
1
2
| var a = <1, 2, 3>; var b = <1, 2, 3 > 5>; // en nu? |
. Ik heb denk ik niet zo'n zin om heel moeilijk te gaan doen door te kijken of een > een groter-dan is of een einde-tuple. Momenteel verslikt de parser zich zelfs over <1, 2, 3> omdat hij bij de laatste 3 wil parsen als '3 groter-dan ERROR'[ Voor 19% gewijzigd door .oisyn op 31-03-2009 18:32 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Verwijderd
Lijkt me ook duidelijker! ik vind <1, 2, 3 > 5> niet echt leesbaar. Ik moet twee keer kijken om 't goed te begrijpen. <1, 2, 3, (3 > 5) > vind ik veel duidelijker.:
Ik kom in de problemen met m'n tuples
code:
Ik kan natuurlijk voor een andere syntax gaan, zoals [[a,b]] of <:a,b:> of (.a,b.) (ik noem maar wat). De mogelijkheden zijn eindeloos
.edit: hmm, ik kan denk het denk ik wel zo krijgen dat een groter-dan nooit die betekenis heeft binnen een tuple, tenzij er haakjes om die expressie staan. <1, 2, 3 > 5> is dus een parse error, dan moet je <1, 2, (3 > 5)> gebruiken.
Zoiets is een best lastige taak voor de compiler(bouwer). Welke informatie heeft de compiler nodig om te kunnen bepalen dat iets in parallel kan worden gedraaid? Welke informatie heeft de compiler nodig om te bepalen of het waard is om iets te parallelliseren? Met welke evaluatiestrategie?
1
2
3
| someList `using` parListChunk 64 rnf -- knip de lijst in stukjes van 64 lang en evalueer de chunks in parallel -- (rnf = reduce normal form) |
Heb je ook overwogen om (a,b,c) te gebruiken voor de tupelsyntax?
[ Voor 10% gewijzigd door RayNbow op 31-03-2009 20:00 ]
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Hoe maak je hieruit op dat addFunc 2 parameters heeft?
[type] gaat niet werken, die gebruik ik al voor array literals: a = [1, 2, 3, 4]. Daarnaast, hoe had jij hashmaps voorgesteld? Ik definieer die nu als int[string] (een hashmap van int values met string keys)
Kan best, maar het lost vrij weinig op als je dat soms dacht
. Verder: a(b), Is dat een functie aanroep, of een cast (en doet dat er eigenlijk toe?).
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Excuses, dat had natuurlijk addFunc:int->int->int moeten zijn. Dit zie je ook veel in ML-afgeleide-talen.
Misschien een domme vraag, maar waarom gaat dat niet werken? Ondanks dat je de [] ook gebruikt voor array-literals zie ik niet waarom je die [] niet zou kunnen gebruiken binnen je type-declaratie.
Geen idee, hoe doet men dat in C++?:
[...]
Kan best, maar het lost vrij weinig op als je dat soms dacht
PC load letter? What the fuck does that mean?
Omdat ik C-style variabel definities gebruik
1
2
3
4
| int a; [int] b; [mytype] c; [1]; // oeps, array literal |
. Dan kun je zeggen: dan moeten je var defs zo zijn: a : int, maar dat conflicteert weer met de 'foreach'1
2
| for (i : [1, 2, 3])
// ... |
C++ is geen goede indicatie omdat je tijdens het parsen al kunt weten wat types zijn en wat niet. En voor de situatie waarin je dat niet kunt weten, zoals in templates, moet je dan ook het keyword typename gebruiken:
1
2
3
4
5
| template<class T> void foo() { T::bar(34); // nested type, or static function? Compiler assumes function typename T::bar(34); // now it's a type } |
[ Voor 45% gewijzigd door .oisyn op 01-04-2009 10:53 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Volgens mij niet. Een cast is gewoon een functie van het ene type naar het andere. Maar sommige casts moeten build-in zijn omdat de taal het soms niet op een andere manier kan. Dan nog is het gewoon een build-in functie. In C++ kan je alle pointer casts zo schrijven (uit mn hoofd...)::
Kan best, maar het lost vrij weinig op als je dat soms dacht
[ Voor 10% gewijzigd door Zoijar op 01-04-2009 11:16 ]
1
| MyClass a = b as MyClass; |
1
2
3
| MyClass a = b -> MyClass // of MyClass a = b cast MyClass |
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Ok, denk er maar over na. Alles behalve die ronde haken C cast:
Geen pointers. Overigens heb ik ook de "as" operator geleend uit C# (een dynamic_cast op pointer niveau zeg maar)
code:
Dat is heerlijk om te parsen. Voor harde casts (dynamic_cast met reference) zou ik ook iets als dit kunnen doen:
code:
Ik heb nog even na zitten denken aan die function-style casts, en het punt is dat ik die dingen dan moet gaan zitten resolven in m'n VM, en dus niet puur aan de AST alleen kan zien of iets een cast is of niet.
Het voordeel van een cast keyword is bovendien dat je erop kunt zoeken
Ja...Het is trouwens built-in
Dat doe ik dus altijd fout, op de een of andere manier krijg ik dat er niet in. Al die d/t werkwoorden trouwens.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| namespace ns
{
class MyClass : MyInterface
{
private static int myVar = 34;
public fn foo() -> (int, float, string, fn(int)->(int))
{
print("hi there");
int[] i = new int[34];
try
{
for (int j : [1, 2, 3, 4])
alert(j * 3);
throw i[34].toString();
}
catch(Exception e)
{
print("Caught exception");
}
finally
{
something();
}
return (1, 2 cast float, "hoi", fn(int a)->(int){ return a + 4; });
}
}
} |
[ Voor 68% gewijzigd door .oisyn op 01-04-2009 18:20 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Heb je het keyword "fn" echt nodig?:
Met dank aan JeromeB voor het fn keyword, ik zat er idd over te denken om "function" in te korten naar "f" of "func" oid, maar "fn" vind ik wel een goede
Het volgende parset nu prima
code:
[ Voor 15% gewijzigd door MLM op 01-04-2009 19:22 ]
-niks-
. Maar op die plek is het idd niet meteen nodig, maar voor lambda's midden in code zeker wel. En houdt er rekening mee dat het een free-form taal is, in de global scope kunnen dus ook gewone statements staan (en dan heb je nog function definitions *in* functies). En dan wordt het ook vrij lastig om een functie-definitie te herkennen.
[ Voor 7% gewijzigd door .oisyn op 01-04-2009 19:20 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Mja, was al aant editten, soz:
De argumenten komen na de identifier, na de -> komen de return-values
[ Voor 10% gewijzigd door MLM op 01-04-2009 19:24 ]
-niks-
1
2
3
4
5
6
7
8
9
10
11
12
13
| class Someclass
{
private Timer timer;
public fn Someclass()
{
timer = new Timer(10, iteration);
}
protected fn iteration()
{
alert(foo(3));
}
} |
)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Wanneer kan A die call afhandelen dan? Ik bedoel, is het niet gewoon een thread die ook code runt? Of wil je dat ie een soort van (handmatige) message loop doet, wachtend op commando's van andere threads.
Klinkt een beetja als C++0x's futures (let wel, dit is niet de final proposal, maar wel het beste artikel dat ik kon vinden met de meeste achtergrond-informatie, in plaats van wat droge bewoording uit de C++ standaard
)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Juist.
Weeral juistKlinkt een beetja als C++0x's futures (let wel, dit is niet de final proposal, maar wel het beste artikel dat ik kon vinden met de meeste achtergrond-informatie, in plaats van wat droge bewoording uit de C++ standaard
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| active class B
{
public fn foo() -> (int) { ... }
}
active class A
{
public fn asynchandler(int)
{
// doe iets
}
public fn foo()
{
async b.foo() asynchandler
}
} |
1
2
3
4
| if (currentThread() == objectAssignedThread) direct_call() else dispatch_call() |
[ Voor 21% gewijzigd door H!GHGuY op 04-04-2009 11:50 ]
ASSUME makes an ASS out of U and ME
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class MyException extends Exception {}
class MyMoreSpecificException extends MyException {}
function something () {
throw new MyMoreSpecificException ("Message");
}
try {
something();
} catch ( MyMoreSpecificException specific ) {
// ...
} catch ( MyException generic ) {
// ...
} |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| exception MyException<const string type> {
const string TYPE_A = "A";
const string TYPE_B = "B";
}
fn something () {
throw MyException<MyException.TYPE_A> ( "Message" );
}
try {
something ();
} catch (MyException<MyException.TYPE_B> specific) {
} catch (MyException generic) {
} |
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
. Maar dat is waarschijnlijk ook omdat je geen constructors in de exceptions hebt gedefinieerd, en volgens mij is dat precies waar het probleem ligt. Het blijft niet bij gewoon een "class B extends A { }" tikken. Maar zou het dan niet een betere oplossing zijn als je het wel daarbij kon laten, en nog steeds B kon constructen met argumenten uit de ctor van A, zonder dat je de ctor van B expliciet moet definieren? 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| class A
{
public fn A(string s) { }
}
class B : A
{
}
class C : A
{
public fn C(int i) { }
}
class D : A
{
using A;
public fn D(int i) { }
}
B b = new B("woei"); // ok, B ctor default inherit van A
C c = new C("woei"); // error, de definitie van C(int) hide de ctors van A
D d = new D("woei"); // ok, de ctors van A worden expliciet geinherit door de using declaration |
[ Voor 28% gewijzigd door .oisyn op 28-04-2009 18:03 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Nou, probleem niet, maar het is op twee manieren eleganter vind ik. Het voorbeeld is misschien niet zo goed, misschien is dit duidelijker:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| fn doQuery() {
try {
// do some query
} catch(SqlException<SqlException.DUPLICATE_KEY> e) {
// doQuery knows how to fix this one
}
}
fn runApp() {
try {
doQuery();
} catch(SqlException<SqlException.CONSTRAINT_ERROR> e) {
// runApp knows how to fix this one
}
}
try {
runApp();
} catch(SqlException<SqlException.CONNECTION_ERROR> e) {
// etc...
} |
1
2
3
4
5
| try {
//
} catch (SqlException e, e.type == SqlException.DUPLICATE_KEY) {
} |
Dat vind ik sowieso een goed ideeJe twee voorbeelden verschillen niet heel veel van elkaar in aantal regels code namelijk
Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/28900/sharingan.gif?f=community)
:strip_exif()/u/185685/walking_boxes_s.gif?f=community)
/u/81985/crop566b00b43645a.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
:strip_exif()/u/28687/tomoi.gif?f=community)
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
:strip_icc():strip_exif()/u/29960/elrond.jpg?f=community)
/u/7685/ruinmytune-60x60.png?f=community)
:strip_icc():strip_exif()/u/35767/images.jpg?f=community)
:strip_icc():strip_exif()/u/92296/sinister.jpg?f=community)
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
:strip_exif()/u/72391/Pinky_and_the_Brain_-_Brain.gif?f=community)
:strip_exif()/u/80759/monstermania_small.gif?f=community)
:strip_exif()/u/119637/logo.gif?f=community){kind=logo}
:strip_exif()/u/22119/ch.gif?f=community)