Ontwerp nieuwe programmeertaal - Softwareontwikkeling

woensdag 27 augustus 2008 12:24

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Modbreak:Afgesplitst van PHP als loose typed taal

prototype schreef op woensdag 27 augustus 2008 @ 02:56:
Anyways, onder het mom van "beter er iets aan doen dan er over te zeuren", loop ik nu al een tijdje met het idee om een dialect te bedenken op PHP en daar ook een VM implementatie op te maken. Ik denk dat de meeste mensen wel een alternatief zouden willen gebruiken als de leercurve voor ze niet (te) hoog ligt. Erik Meijer (functional programming god @ microsoft research) heeft er wel eens over geschreven dat ook al onderkennen programmeurs het probleem met een taal, dat men het toch blijft gebruiken als het leren van een ander taal teveel werk is. Het is om deze reden dat het me geen gek idee lijkt om qua syntax niet teveel af te wijken van PHP in zo'n geval, maar wel met fatsoenlijke constructies voor bijvoorbeeld closures.

Helaas zit ik nogal zwaar verlegen met de tijd ivm werk en studie, maar misschien dat er mensen hier zijn die zich tot hetzelfde geroepen voelen. Als ik hier nog over een jaar mee rondloop met ditzelfde idee zal ik het eens voorleggen aan een van m'n docenten om hier een master research project van te maken (voor de duidelijkheid, ik ben iig niet van plan om met zoiets saais af te studeren ). Om eerlijk te zijn interesseert de grammatica van de taal me niet bijster veel, 't gaat mij meer om de VM maken, maar als ik 't voor het zeggen zou hebben zou ik de grammatica niet op PHP laten lijken. Na x jaar blijkt echter nog steeds dat PHP het meest gebruikt wordt voor webdev en om nou iets te maken dat niemand gebruikt...

Daar ben ik een x jaar geleden eens mee begonnen, onder de noemer Orbb. Geen PHP dialect, maar wel een (naar eigen zeggen dan

) degelijk ontworpen taal die op hetzelfde niveau inzetbaar is als PHP (dus gewoon een script per request, en inline code embedded in een document). Afgezien van de initialisatie (goed, als CGI app kon ik natuurlijk niet competen met mod_php

) was het wel sneller

. Dit is natuurlijk ook weer gestrand wegens gebrek aan tijd.

Als je dit ooit nog op wilt pikken dan wil ik wel meedoen

. PHP dialect vind ik op zich prima, maar laten we op z'n minst die achtelijke $ notatie de das om doen

[ Voor 5% gewijzigd door Creepy op 07-09-2008 17:09 ]

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.

woensdag 27 augustus 2008 15:18

Acties:

0 Henk 'm!

prototype

Cheer Bear

Manuzhai schreef op woensdag 27 augustus 2008 @ 10:22:
[...]
Open classes zijn namelijk zo'n lekker goed idee, dat zorgt in Rails ook helemaal niet voor problemen.

Het is een feature die imho helemaal past bij een dynamische taal en welke je verstandig dient te gebruiken. Monkey patchen onder voorbehoud dus. Ik zie het niet anders zijn dan een mes: in de handen van een kok, excellent, in de handen van een psychopaat, not so excellent

.

Goed voorbeeld: in javascript (prototype based OO) kun je toch ook prototypes (no pun intended) naar gelang aanpassen (en zo in feite ook 'open classes' bewerkstelligen? Bij verstandig gebruik is daar gewoon helemaal niks op aan te merken.

.oisyn schreef op woensdag 27 augustus 2008 @ 12:24:
[...]

Daar ben ik een x jaar geleden eens mee begonnen, onder de noemer Orbb. Geen PHP dialect, maar wel een (naar eigen zeggen dan ) degelijk ontworpen taal die op hetzelfde niveau inzetbaar is als PHP (dus gewoon een script per request, en inline code embedded in een document). Afgezien van de initialisatie (goed, als CGI app kon ik natuurlijk niet competen met mod_php ) was het wel sneller . Dit is natuurlijk ook weer gestrand wegens gebrek aan tijd.

Als je dit ooit nog op wilt pikken dan wil ik wel meedoen . PHP dialect vind ik op zich prima, maar laten we op z'n minst die achtelijke $ notatie de das om doen

Ah ja, Orbb, 'k meen zoiets nog gezien te hebben op je site toentertijd na een willekeurige klik actie op de huisjesicoontjes van mensen hier op GoT

. Ik denk dat het er toch echt best in zit dat ik dit kan voordragen voor 10 tot 15 ects, en dan wil ik hier best wel werk van maken: vanzelfsprekend zou ik het uber tof vinden als je mee zou doen tegen die tijd

.

Zelf zit ik momenteel uit gezonde interesse LLVM te bestuderen en voor zover ik het kan zien lijkt het me dat je heel veel dingen gratis kan krijgen, zoals JIT compilation door gebruik te maken van de intermediate representation van LLVM. Als we write barriers erbij implementeren kunnen we dan ook een fatsoenlijke garbage collector maken (e.g. generational). Maar goed, allemaal toekomst muziek nog, maar zeker iets waar ik m'n handen wel even aan wil branden. Tof onderwerp lijkt me ook voor OSCON 2010 ofzo

(tenminste, als het open source wordt).

Wat betreft $, urgh, als er 1 ding is waar ik me aan heb ge-ergerd in PHP is het dat wel. Alle Perlism's eruit so to say

. Ok, de regexps mogen er wel in blijven, maar dan wel met syntactisch suiker

. Zelf zou ik ooit pattern matching er ook in willen zien zoals je dit terugvindt in b.v. erlang.

[ Voor 4% gewijzigd door prototype op 27-08-2008 16:18 ]

vrijdag 5 september 2008 23:08

Acties:

0 Henk 'm!

prototype

Cheer Bear

T.T. schreef op vrijdag 05 september 2008 @ 18:52:
Haha per definitie is dat natuurlijk waar.

Wellicht is ons enige verschil dat jij zowel de taal als het gebruikk van PHP verwerpt (als ik het goed begrijp) omdat het onvolkomenheden heeft. Terwijl ik PHP gebruik omdat het nog steeds beter is dan de alternatieven (en dan met name CGI's in C++ yuk). Anderen zouden uit jouw argumentatie immers kunnen opmaken dat ze geen PHP moeten gebruiken, dat wil ik even rechtzetten (met de voetnoot dat er 'wat' rare dingen in de taal zitten)

Mag ik vragen welke alternatieven je hebt gebruikt? Een taal als ruby of python vind ik namelijk nog steeds shitloads beter in elkaar steken dan PHP. Niet alleen van een technisch implementatie standpunt (zoals ik die al hier heb genoemd in dit topic) maar ook vanuit een design standpunt (zoals we hier ook al hebben aangekaart).

Anyways, 'k heb even vandaag gewerkt aan een voorstel voor een betere PHP: i.e. een taal die lijkt op PHP, maar stiekem alle awesome features van smalltalk/ruby/python heeft. Hier kunnen denk ik de meeste PHP'ers wel kaas van maken neem ik aan

code:

/**
 * This is a proposal for the implementation of the programming
 * language "Poisyn" (tentative name for prototype + oisyn)
 *
 * Some general language rules:
 * Denoting the end of a statement can be done with
 * either a newline or a ;
 * Parenthesis may be omitted for brevity's sake.
 */
module SomeModule {

    public static function foo() {
        # Needless to say, this string will be interned.
        return "I am a static method!"
    }

    /**
     * Instance method that will be mixed in
     * with a class that includes this module
     */
    public function contains?(Object o) {
        return this.collection.contains(o)
    }
}

class Foo extends Bar {
    # Mixin a module
    include SomeModule
    
    private int x;
    private a;
    
    # Sugar: Object#attr_reader :a
    # Note: omitting qualifier <=> module public
    function a {
        return this.a
    }
    
    # Sugar: Object#attr_writer :a
    public function a=(v) {
        this.a = v
    }
    
    # Sugar for both reader and writer:
    attr_accessor :x
    
    /**
     * This is an example of a method that can be
     * optimized on return type seeing as it'll
     * __always__ return an anonymous function with
     * its closure.
     */
    public function something(int a, int b, string c = "haiz!") {
        this.a = a;
        if (this.a == a) {
            closure = function(x, y) {
                print c
                return [x,y]
            }
            
            return closure(a,b)
        } else {
            return function() {
                print "Tsjah..."
            }
        }
    }
    
    /**
     * Through static analysis, it can also be inferred
     * that this method will return 'void'.
     */
    public function foobar(o) {
        print this.hash_code == o.hash_code
    }
    
    /**
     * Note that the ? is a valid trailing identifier
     * Its semantics will be given to predicates.
     */
    private function contains?(Object o) {
        return super.contains?(o)
    }
    
}

# An array
foo = ["Hello", "world", "!!"]
foo << "Invocation of Array#<<(arg) instance method, i.e. array append"
foo.each function(element) {
    println(element)
}

# What about array() you're probably wondering? Well, we could do that retarded way as well :P
function array(args...) {
    return args;
}

some_array = array("haiz", "kthnxbyez")

# If we want == to behave the same way as PHP for arrays, reopen the Array class and override the == operator.
class Array {
    function ==(arr) {
        if(this.size == arr.size) {
            for(i = 0; i < arr.size; i++) {
                if(arr[i] != this[i]) {
                    return false
                }
            }
            return true
        } else {
            return false
        }
    }
}

# Hashmap, i.e. associative array sugar
map = {:foo => "bar", :dude => "sweet"}
map << (:foooooo, "baz") # equivalent to statement below (based on formal definition of map)
map << {:blaat => "aap"} # equivalent to statement above

map.each function(key, value) {
    println(key)
    println(value)
}

symbol = :foo
a = :foo
b = :foo

print(a == b) # Always true

for(f in foo) {
    println(f)
}

for(pair in map) {
    # Key, value extraction from pair
    x,y = pair
    
    # String interpolation through #{foo}
    println("x was: #{x}")
    println("y was: #{y}")
}

foo_instance = new Foo();
func = foo_instance.something(0, 0)
x,y  = func.call()

# Invocation of foobar method through message passing for dynamic method invocation
# Object#send(method_name, method_args...)
foo_instance.send(:foobar, null)

print(foo_instance instanceof SomeModule) # true, i.e. class is a mixed in type
# Multiple inheritance could be established through mixing in multiple modules

/**
 * The language should be completely object oriented, i.e. elements that are considered by other
 * languages to be literals are in fact, flyweight objects in our language.
 * The following yields "NullClass"
 */
print(null.class)

# In a similar fashion, we have TrueClass, and FalseClass etc...
print(true.class)
print(false.class)

# Regular expressions will get syntactic sugar as well through / /.
# The following should yield RegEx
print(/^haiz$/i.class)

# Now for some of the exciting stuff, let's talk about co-routines.
# You may already know of this concept under the name of fibers.
x = new Coroutine function() {
    i = 0
    while(true) {
        i++
        Coroutine.yield(i)
    }
}

println(x.resume) # Prints out 1
println(x.resume) # Prints out 2
println(x.resume) # Prints out 3
# etc...

Feedback is altijd welkom

[ Voor 10% gewijzigd door prototype op 06-09-2008 02:15 . Reden: Kleine update van de 'spec' ]

vrijdag 5 september 2008 23:46

Acties:

0 Henk 'm!

Gomez12

prototype schreef op vrijdag 05 september 2008 @ 23:08:
[...]
Feedback is altijd welkom

Enige vraag : Waarom nog een taal?

PHP kan je klote en slecht vinden, maar het heeft ondertussen wel een functionaliteit waar je als beginnend programmeertaaltje U tegen zegt.
Imho als je php echt zo slecht vind probeer dan mee te helpen aan php en die te verbeteren, of pak een andere taal om aan mee te werken.
Het beginnen aan een nieuw taaltje is in 99,9% van de gevallen afaik niet realistisch omdat het gewoon een te langdurig proces is, zolang jij niet in de buurt komt van de functionaliteit van php krijg je weinig mensen die van php overstappen.
Imho zolang je weinig gebruikers hebt van jouw taaltje krijg je weinig goede coders die meehelpen, oftewel het kost jou ongelovelijk veel tijd.

Ik zie alleen in dit topic al 2 mensen die ik redelijk serieus neem die een taaltje probeerden op te starten maar tijdelijk afhaakten omdat er te veel tijd in ging zitten.

Misschien kan je het maken, maar besef je wel goed hoeveel tijd dit gaat kosten ( je moet niet alleen de taal maken, maar ook gelijk de community entertainen die het gebruikt )...

zaterdag 6 september 2008 00:16

Acties:

0 Henk 'm!

roy-t

Denoting the end of a statement can be done with
* either a newline or a ;

Sorry maar ik vind "of of" in dit geval echt vreselijk.

-Of je kiest de C methode van sluiten met een ';' wat imho erg goed past bij het hele curley braces gebeuren.

-Of je kiest voor een taal die meer op de menselijke taal lijkt een beetje Visual Basic Achtig ala met afsluiting een '.' of met een '\n' (enter)

code:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim voorbeeldzin As String = "Hello World"
    Dim antwoord As Microsoft.VisualBasic.MsgBoxResult = MsgBoxResult.No
    Do While antwoord <> MsgBoxResult.Yes
        MessageBox.Show(voorbeeldzin)
        antwoord = MessageBox.Show("Programma sluiten?", "Hello World", MessageBoxButtons.YesNo)
    Loop
    Me.Close()
End Sub

Maar dat halfslachtige of of gebeuren krijg je eigenlijk alleen maar lelijke code mee imho

Btw ik zou heel erg voor zijn als wordt nu eindelijk eens ':=' als syntax heeft en is dan een enkele '='. Dan is de aansluiting met logica/wiskunde veel groter

.

[ Voor 7% gewijzigd door roy-t op 06-09-2008 00:17 ]

~ Mijn prog blog!

zaterdag 6 september 2008 00:30

Acties:

0 Henk 'm!

prototype

Cheer Bear

Gomez12 schreef op vrijdag 05 september 2008 @ 23:46:
[...]

Enige vraag : Waarom nog een taal?

Omdat ik nog 15 ECTS tekort kom

Begrijp me niet verkeerd, maar in eerste instantie zal ik deze taal implementeren om mijn kennis van virtual machines te vergroten. oisyn's doel is hier niet anders in

. De mogelijkheden die 't moet kunnen ondersteunen zijn meer dan PHP als taal in faciliteert. Vandaar dus een taal die dit ondersteund, die hierbij lijkt op PHP zodat mensen die al bekend zijn met PHP zich bekend zullen voelen met de meeste taalconstructies. Dat neemt dus niet weg dat er een PHP vertaler geschreven kan worden als de bytecode instructies eenmaal vast staan.

PHP kan je klote en slecht vinden, maar het heeft ondertussen wel een functionaliteit waar je als beginnend programmeertaaltje U tegen zegt.
Imho als je php echt zo slecht vind probeer dan mee te helpen aan php en die te verbeteren, of pak een andere taal om aan mee te werken.

En wat nou als ik zeg dat ik de Ruby garbage collector samen met een vriend copy on write friendly heb gekregen? ;-) En wat nou als ik ook zeg dat ik in een grijs verleden ook heb meegecontribute aan die taal die jij nu zo geweldig vind, PHP that is. Oftewel, been there, done that (and still doing it ;-)). Dat weerhoud me er echter niet van om zelf een VM te implementeren omdat ik denk dat dat de beste manier is om kennis te vergaren ervan: het alleen lezen van de wetenschappelijke artikelen laat net iets teveel aan de verbeelding over.

Binnen deze thread heb ik ook al enkele punten aangetoond waar de Zend VM gewoon schromelijk imho in tekort schiet: de meeste dingen zijn gewoon zo geimplementeerd omdat het 'makkelijker is om het zo te implementeren'. Niet zozeer omdat het de beste performance/flexibiliteit biedt! En dat refactor je niet zomaar even (lees: daar heb ik geen zin in, over slechte code gesproken).

Het beginnen aan een nieuw taaltje is in 99,9% van de gevallen afaik niet realistisch omdat het gewoon een te langdurig proces is, zolang jij niet in de buurt komt van de functionaliteit van php krijg je weinig mensen die van php overstappen.
Imho zolang je weinig gebruikers hebt van jouw taaltje krijg je weinig goede coders die meehelpen, oftewel het kost jou ongelovelijk veel tijd.

Oh dit realiseer ik me ook

Er zit een hele redelijke kans in dat het ook niet af komt, maar dat is niet erg zolang ik er wijzer uit ben gekomen. Als ik "het afkrijgen" als de hoogste prioriteit had, dan had ik voor een bestaande VM gekozen en er enkel de vertaler en bytecode generator voor geschreven. But where's the fun in that?

Dat heb ik al gedaan bij vertalerbouw, een VM bouwen daarentegen nog niet. De kennis zou ik theoretisch gezien nu moeten hebben, nu de praktijk ervaring nog ^_^

Ik zie alleen in dit topic al 2 mensen die ik redelijk serieus neem die een taaltje probeerden op te starten maar tijdelijk afhaakten omdat er te veel tijd in ging zitten.

Misschien kan je het maken, maar besef je wel goed hoeveel tijd dit gaat kosten ( je moet niet alleen de taal maken, maar ook gelijk de community entertainen die het gebruikt )...

Het zou een leuke bijkomstigheid zijn als mensen uit de community het ook zouden gebruiken, maar dat is (en dat klinkt misschien vreemd), niet mijn eerste zorg. Het gaat me wederom meer om de virtual machine die gebouwd wordt. Wanneer de instructieset in orde is zou een PHP vertaler ervoor niet onmogelijk zijn. Echter als je van plan bent meer features in je VM te zetten dan PHP ondersteund dien je je eigen taal te bedenken om hierin te voorzien. Daarom dit voorstel dus

.

roy-t schreef op zaterdag 06 september 2008 @ 00:16:
[...]

Sorry maar ik vind "of of" in dit geval echt vreselijk.

-Of je kiest de C methode van sluiten met een ';' wat imho erg goed past bij het hele curley braces gebeuren.

-Of je kiest voor een taal die meer op de menselijke taal lijkt een beetje Visual Basic Achtig ala met afsluiting een '.' of met een '\n' (enter)
code:
1
2
3
4
5
6
7
8
9
10
11
12
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim voorbeeldzin As String = "Hello World"
    Dim antwoord As Microsoft.VisualBasic.MsgBoxResult = MsgBoxResult.No
    Do While antwoord <> MsgBoxResult.Yes
        MessageBox.Show(voorbeeldzin)



        antwoord = MessageBox.Show("Programma sluiten?", "Hello World", MessageBoxButtons.YesNo)
    Loop
    Me.Close()
End Sub
Maar dat halfslachtige of of gebeuren krijg je eigenlijk alleen maar lelijke code mee imho

Btw ik zou heel erg voor zijn als wordt nu eindelijk eens ':=' als syntax heeft en is dan een enkele '='. Dan is de aansluiting met logica/wiskunde veel groter .

Ruby en javascript werken anders ook zo en daar heb ik echt niet 'alleen maar lelijke code' mee gezien ;-). Sterker nog, 'k heb meer lelijke C/C++ code gezien, maar dat lag echt niet alleen aan de lexicale token ';' ;-)
Wat betreft ':=', dat wordt idd veel in pseudo code gebruikt, maar in een taal dat veel leent van Ruby/PHP/Java lijkt me het niet echt geplaatst. Misschien zouden we het als een overloadable operator kunnen introduceren, die in de standaard implementatie gebruik maakt van Object#=(value).

Een ding dat ik me iig realiseer is dat "//" gebruiken voor een singleline comment niet gaat werken als ik / / bijvoorbeeld ook wil gebruiken voor regexps, e.g. /^haiz$/.match("haiz") omdat je een regexp kan hebben die geen karakters bevat, i.e. //. Dat zorgt voor een non-deterministische situatie. Misschien de pound sign dan maar gebruiken voor single line comments, i.e. # dus.

[ Voor 25% gewijzigd door prototype op 06-09-2008 01:09 . Reden: non determinant.... non deterministisch dus, 'tis laat -_-" ]

zaterdag 6 september 2008 01:09

Acties:

0 Henk 'm!

Gomez12

prototype schreef op zaterdag 06 september 2008 @ 00:30:
[...]
Begrijp me niet verkeerd, maar in eerste instantie zal ik deze taal implementeren om mijn kennis van virtual machines te vergroten. <snip>
Vandaar dus een taal die dit ondersteund, die hierbij lijkt op PHP zodat mensen die al bekend zijn met PHP zich bekend zullen voelen met de meeste taalconstructies.

Als het je alleen om de kennis gaat dan applaus voor u. Het is niet het minste of geringste wat je even durft op te pakken.

En wat nou als ik ook zeg dat ik in een grijs verleden ook heb meegecontribute aan die taal die jij nu zo geweldig vind, PHP that is.

Kleine misvatting, ik vind PHP niet geweldig. Ik kan alleen ondertussen om de grootste fouten heenwerken waardoor het werkbaar wordt, net zoals dat geldt voor C / C++ etc.

de meeste dingen zijn gewoon zo geimplementeerd omdat het 'makkelijker is om het zo te implementeren'. Niet zozeer omdat het de beste performance/flexibiliteit biedt!

Ben je niet bang dat je dit zelf ook gaat doen? Soms is de verleiding toch wel heel erg groot om iets gewoon af te hebben al is het dan niet perfect. En later zit je dan met de legacy brokken van 1x de verleiding niet kunnen weerstaan... Zoals je zelf al zegt, het refractoren kost ongelovelijk veel tijd...

[...]
Een ding dat ik me iig realiseer is dat "//" gebruiken voor een singleline comment niet gaat werken als ik / / bijvoorbeeld ook wil gebruiken voor regexps, e.g. /^haiz$/.match("haiz") omdat je een regexp kan hebben die geen karakters bevat, i.e. //. Dat zorgt voor een non-determinante situatie. Misschien de pound sign dan maar gebruiken voor single line comments, i.e. # dus.

Imho zoek je het probleem de verkeerde kant uit , ik pretendeer niet een programmeertaal te schrijven

maar met elk willekeurige karakter krijg je toch hetzelfde probleem. Een regex / string kan alles bevatten, als je // niet kan gebruiken vanwege regexps dan kan je volgens mij geen enkel teken gebruiken.
Of stel als eis dat je comment altijd binnen de code moet liggen ( dus je negeert alle comments binnen regexps / tussen quotes etc ) , of ga voor de simpele oplossing en stel dat een regel moet beginnen met een comment sign ( lijkt mij hardstikke irritant om op deze manier te moeten proggen maarja ik kan dan ook slecht zonder inline comments )

zaterdag 6 september 2008 01:36

Acties:

0 Henk 'm!

prototype

Cheer Bear

Gomez12 schreef op zaterdag 06 september 2008 @ 01:09:
[...]

Ben je niet bang dat je dit zelf ook gaat doen? Soms is de verleiding toch wel heel erg groot om iets gewoon af te hebben al is het dan niet perfect. En later zit je dan met de legacy brokken van 1x de verleiding niet kunnen weerstaan... Zoals je zelf al zegt, het refractoren kost ongelovelijk veel tijd...

Klopt misschien, maar het refactoren wordt een stuk makkelijker als je modulair werkt, iets wat de PHP source imho erg in lacked ook (het ontbreken van documentatie vind ik nog wel de meest ernstige). Daarbij ga ik dit project niet in m'n eentje aan, .oisyn doet ook mee

en die trapt me denk ik wel als ik iets ranzigs schrijf, en omgekeerd mag hij dat ook van mij verwachten (alhoewel ik dat niet verwacht :-)). Bovendien geloof ik dat Edsger Dijkstra met m'n code meekijkt en "er niet blij mee zou zijn als ik af zou wijken van zijn teachings" ;-) .

[...]

Imho zoek je het probleem de verkeerde kant uit , ik pretendeer niet een programmeertaal te schrijven maar met elk willekeurige karakter krijg je toch hetzelfde probleem. Een regex / string kan alles bevatten, als je // niet kan gebruiken vanwege regexps dan kan je volgens mij geen enkel teken gebruiken.

Nee, een lexical analyzer (lexer) groepeert karakters tot tokens, welke door de parser (een recursive descent parser b.v.) gebruikt worden om een parse tree mee op te bouwen. Het probleem zit hem in het feit dat als de lexer een / tegenkomt, dat hij moet bepalen wat dit is en/of het onderdeel uitmaakt van een grotere token. Een string bijvoorbeeld begint en eindigt met een quote. Wanneer de lexer een " tegenkomt, zal hij zich als een state machine gedragen om de string te bepalen. Wanneer hij aan het einde van de source is maar geen " meer tegenkomt is de statemachine in een unaccepted state terecht gekomen en dat resulteert in een lexer error

. Het probleem zit hem in het feit dat de / zowel de eerste als laatste karakter kan zijn van een single commentline token, of de begin/eind delimiter kan zijn van een Regexp. Er is dus een keuze waarbij je niet weet welke branch kiezen de juiste is, i.e. tot de accepterende toestand leidt. Je zou dit soort problemen eventueel met een (grotere) lookahead kunnen oplossen, maar het probleem hierbij is dat "//" gewoon ambigu is (i.e. een lookahead k=99999999999999999 zou dit niet oplossen ;-)). That is, is het een singleline comment token of een lege regexp? :-) Oftewel, je hebt een non-deterministisch probleem. Dat ga ik liever uit de weg door // niet te gebruiken voor singleline comments b.v. of zoals je voorgesteld had, een string hiervoor te misbruiken.

Kleine "spec" update

[ Voor 6% gewijzigd door prototype op 06-09-2008 02:16 ]

zaterdag 6 september 2008 10:26

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

prototype schreef op vrijdag 05 september 2008 @ 23:08:
Mag ik vragen welke alternatieven je hebt gebruikt? Een taal als ruby of python vind ik namelijk nog steeds shitloads beter in elkaar steken dan PHP. Niet alleen van een technisch implementatie standpunt (zoals ik die al hier heb genoemd in dit topic) maar ook vanuit een design standpunt (zoals we hier ook al hebben aangekaart).

Dat talen beter zijn maakt ze nog geen betere alternatieven voor php

Anyways, 'k heb even vandaag gewerkt aan een voorstel voor een betere PHP: i.e. een taal die lijkt op PHP, maar stiekem alle awesome features van smalltalk/ruby/python heeft. Hier kunnen denk ik de meeste PHP'ers wel kaas van maken neem ik aan

Het is natuurlijk interessant om zoiets te maken. Maar het zal natuurlijk wel heel veel beter in elkaar moeten steken dan php en dan moet je je niet alleen richten op het 'de code is netter' punt, want dat kan de meeste php-coders waarschijnlijk niet zo veel schelen. Dat de rariteiten van php weg zijn is ook niet zo interessant, de meeste loop je maar zelden tegenaan in je code.

Wat ze wel kan schelen is als ze met minder, maar even duidelijke syntax dezelfde functionaliteit kunnen bereiken. En een deel zal geinteresseerd zijn in betere performance, een statefull omgeving, minder geheugenoverhead en dat soort dingen die nu in php nog missen of echt ondermaats zijn.

* Denoting the end of a statement can be done with
* either a newline or a ;

Ik vind het hele 'een newline eindigt je statement' tamelijk waardeloos. Vooral omdat ik te vaak regels heb gezien van meer dan 80 karakters lang, waarvan het best prettig is om ze over meerdere regels te verdelen zonder ze op te splitsen in meerdere statements (voor zover mogelijk). Sowieso is whitespace verder nergens van betekenis in je taal, dus waarom een newline ineens wel?

private a;

# Sugar: Object#attr_reader :a
# Note: omitting qualifier <=> module public
function a {
return this.a
}

# Sugar: Object#attr_writer :a
public function a=(v) {
this.a = v
}

Dit zijn dus wrappers rond een call naar 'object.a' in je code? Een beetje het idee van C++ waar je de = kan herdefinieren?

/**
* Note that the ? is a valid trailing identifier
* Its semantics will be given to predicates.
*/
private function contains?(Object o) {
return super.contains?(o)
}

En wat voegt die ? toe, behalve verwarring? Of is dat een isset-methode, waardoor je if(object.o) {...} kan aanroepen?

# What about array() you're probably wondering? Well, we could do that retarded way as well
function array(args...) {
return args;
}

some_array = array("haiz", "kthnxbyez")

De array is natuurlijk wel wat krachtiger dan dat in php he? Het is tegelijkertijd een hashmap en list. En hoewel het niet altijd prettig is om die twee gemixed te hebben (door de gigantische geheugenoverhead) heeft het ook weer zijn voordelen. Maar let er iig op dat je dergelijke datastructuren triviaal aan je gebruiker aanbiedt, ipv dat je ze dwingt ze zelf te definieren als het wat moeilijker moet zijn dan [a, b, c] of je {:bla ...}.

map = {:foo => "bar", :dude => "sweet"}
map << (:foooooo, "baz") # equivalent to statement below (based on formal definition of map)
map << {:blaat => "aap"} # equivalent to statement above

map.each function(key, value) {
println(key)
println(value)
}

symbol = :foo
a = :foo
b = :foo

Is dat nou perl-style een referentie naar het laatst geopende relevante object? Of had het map:foo moeten zijn?

func = foo_instance.something(0, 0)
x,y = func.call()

Die impliciete list() is wel handig idd. Is het niet handiger om gewoon standaard func() te kunnen aanroepen?

/**
* The language should be completely object oriented, i.e. elements that are considered by other
* languages to be literals are in fact, flyweight objects in our language.
* The following yields "NullClass"
*/
print(null.class)

Is alles dan per definitie niet alleen een instanceof 'Object' maar ook van 'NullClass' ? Aka, als je een functie-definitie opgeeft ala 'function bla(SomeType x)' mag ik dat dan aanroepen met 'bla(null)' zoals in Java of krijg ik dan zoals in php een foutmelding (tenzij je 'function bla(SomeType x=null)' definieert

)

# Regular expressions will get syntactic sugar as well through / /.
# The following should yield RegEx
print(/^haiz$/i.class)

Worden de regexp's duidelijker in de taal geintegreerd dan in perl? Want hoewel het hip is dat het er compleet in geintegreerd zit bij perl, vind ik de manieren van php, Javascript en Java toch eenvoudiger te begrijpen.

# Now for some of the exciting stuff, let's talk about co-routines.
# You may already know of this concept under the name of fibers.
x = new Coroutine function() {
i = 0
while(true) {
i++
Coroutine.yield(i)
}
}

println(x.resume) # Prints out 1
println(x.resume) # Prints out 2
println(x.resume) # Prints out 3
# etc...

Wat je dus zo in php zou kunnen implementeren?

PHP:

function x_resume()
{
 static $i = 0;
return ++$i;
}

Of natuurlijk gewoon met een normale klasse.

Maar is het echt verstandig om op zo'n manier de control-structure over meerdere delen van je code te splitsen? Je kan er vast hele krachtige dingen mee doen, maar er bestaan al in de normale syntax voldoende methoden om iig jouw voorbeeld te bereiken. Wat voegt het toe, waarbij het echt beter is om deze aanpak te gebruiken?

Feedback is altijd welkom

Bij deze wat puntjes

Overigens is .oisyn in de eerdere discussie nog een punt vergeten bij zijn 0 == 'blaat' bij php hetze

Want dit is toch wel een belangrijke reden waarom deze keuze raar is:

PHP:

$a = 'blaat';
$b = 0;
if($a == $b){echo 'a == b';} // true
if($a){ echo 'a == true';} // true
if($b){ echo 'b == true';} // false

Het ergste hierbij is niet eens dat $a naar true evalueert in het tweede statement, maar dat je van $b eigenlijk niet zo eenvoudig kan controleren of het een integer is waarbij 0 ook een geldige waarde is. Kwa aangeboden mogelijkheden komt is_numeric in de buurt, maar een float is geen integer. En domweg casten naar int en kijken of er een integer is, is ook raar want een string is geen int.
Gelukkig is dit met name relevant bij het controleren van user-input en dat doe je doorgaans maar een maal in je script-executie, waardoor je er een regexp of iets in die geest op los kan laten, zonder dat het te duur wordt.

zaterdag 6 september 2008 13:22

Acties:

0 Henk 'm!

prototype

Cheer Bear

ACM schreef op zaterdag 06 september 2008 @ 10:26:
[...]

Dat talen beter zijn maakt ze nog geen betere alternatieven voor php

Mjah, je moet natuurlijk altijd rekening houden met andere factoren dan alleen de technische, e.g. markt van vraag en aanbod etc... En ja, dan is PHP voorlopig nog wel de meest geschikte denk ik voor de meeste bedrijven (helaas) ;-)

[...]

Het is natuurlijk interessant om zoiets te maken. Maar het zal natuurlijk wel heel veel beter in elkaar moeten steken dan php en dan moet je je niet alleen richten op het 'de code is netter' punt, want dat kan de meeste php-coders waarschijnlijk niet zo veel schelen. Dat de rariteiten van php weg zijn is ook niet zo interessant, de meeste loop je maar zelden tegenaan in je code.

Wat ze wel kan schelen is als ze met minder, maar even duidelijke syntax dezelfde functionaliteit kunnen bereiken. En een deel zal geinteresseerd zijn in betere performance, een statefull omgeving, minder geheugenoverhead en dat soort dingen die nu in php nog missen of echt ondermaats zijn.

En dit is dus wat ik met m'n taal voorstel hoop te bereiken

Een taal die erg veel lijkt op PHP (met minder boilerplate) en die ze krachtigere features ook biedt. Qua VM doel ik er hoe dan ook op om middels write barriers een goede generational garbage collector te schrijven die ook compacting is etc... Dat maakt de taal meteen geschikter dus voor statefull omgevingen, e.g. application servers.

[...]

Ik vind het hele 'een newline eindigt je statement' tamelijk waardeloos. Vooral omdat ik te vaak regels heb gezien van meer dan 80 karakters lang, waarvan het best prettig is om ze over meerdere regels te verdelen zonder ze op te splitsen in meerdere statements (voor zover mogelijk). Sowieso is whitespace verder nergens van betekenis in je taal, dus waarom een newline ineens wel?

Zelf heb ik er nooit echt last van gehad in ruby aangezien ik de regels afsplits met nieuwlines op plekken waarbij ik weet dat ze op de volgende regel nog stand houden. E.g.

Ruby:

def foobar(*args)
args.each {|arg| puts arg}
end

foobar("dit", "wordt", "een",
"lange","function",
"call")

Maar goed, laten we de semicolon maar mandatory maken dan

Maakt parsen alleen maar makkelijker ;-)

[...]

Dit zijn dus wrappers rond een call naar 'object.a' in je code? Een beetje het idee van C++ waar je de = kan herdefinieren?

Yes.

[...]

En wat voegt die ? toe, behalve verwarring? Of is dat een isset-methode, waardoor je if(object.o) {...} kan aanroepen?

De vraagteken is een valid identifier die men semantisch dient te gebruiken voor predicaten. Het zijn dus gesloten vragen die altijd een true of false opleveren. contains?(o) larger?(a,b) etc... Als men dit consistent gebruikt in de taal kan men aan de functie/methodenaam zelf al zien wat deze b.v. zou moeten returnen (een boolean). Ik kan me wel vinden in je punt dat dit misschien tot verwarring kan leiden met de ternary if-else.

[...]

De array is natuurlijk wel wat krachtiger dan dat in php he? Het is tegelijkertijd een hashmap en list. En hoewel het niet altijd prettig is om die twee gemixed te hebben (door de gigantische geheugenoverhead) heeft het ook weer zijn voordelen. Maar let er iig op dat je dergelijke datastructuren triviaal aan je gebruiker aanbiedt, ipv dat je ze dwingt ze zelf te definieren als het wat moeilijker moet zijn dan [a, b, c] of je {:bla ...}.

Hmmm, misschien zouden we pattern matching in de taal moeten hebben zoals Erlang dit ook heeft om hier ook syntactisch suiker voor aan te kunnen bieden.

[...]

Is dat nou perl-style een referentie naar het laatst geopende relevante object? Of had het map:foo moeten zijn?

Op welke regel doel je precies?

De eerste regel is een hashmap maken met keys :foo en :dude, die respectievelijk naar "bar en "sweet" mappen.
De tweede regel doet een append van een 2 tuple. Een hashmap is in feite namelijk een functie van het type Object+ -> Object+. Volgens deze formele definitie zouden we dus een 2 tuple mogen appenden aan deze functie van het type (Object+, Object+). Het is in feite dus een robuuste append, die een een key-value paar override als de key al bestaat of anders deze key-value paar opneemt in de map.
De 3e statement doet eigenlijk hetzelfde.

code:

map.each function(key, value) {
println(key)
println(value)
}

Geeft een closure mee aan de each methode van HashMap#each, welke een anonieme functie verwacht met arity=2. Binnen de each methode wordt de closure voorzien van de waarden van key en value, i.e. scope binding vindt plaats.

[...]

Die impliciete list() is wel handig idd. Is het niet handiger om gewoon standaard func() te kunnen aanroepen?

func is hier ook een object he? That is, func instanceof Function/Functor. Misschien zouden we er syntactisch suiker voor kunnen bedenken.

[...]

Is alles dan per definitie niet alleen een instanceof 'Object' maar ook van 'NullClass' ? Aka, als je een functie-definitie opgeeft ala 'function bla(SomeType x)' mag ik dat dan aanroepen met 'bla(null)' zoals in Java of krijg ik dan zoals in php een foutmelding (tenzij je 'function bla(SomeType x=null)' definieert )

Nee, alles is per definitie instanceof 'Object' maar niet van 'nullclass'. Die twee zijn disjoint dus, en zullen net zo behandeld worden als je gewend bent in andere talen. In plaats van een literal, welke normaliter ook als special case behandeld wordt, zal het echter een flyweight instance zijn van NullClass. Op dit na zal het niet anders zijn

[...]

Worden de regexp's duidelijker in de taal geintegreerd dan in perl? Want hoewel het hip is dat het er compleet in geintegreerd zit bij perl, vind ik de manieren van php, Javascript en Java toch eenvoudiger te begrijpen.

Hier verschillen smaken nogal in denk ik. Zelf ben ik de PCRE manier met // suiker onderhand dusdanig gewend dat ik het omgekeerde juist net vindt. Ik heb er daarbij zoals RayNbow ook aankaart liever dat dit op language constructs lijken dan dat we hier de string voor 'misbruiken'. Dit geeft me ook de kans om eventueel optimalisaties uit te voeren tijdens het parsen omdat ik meteen weet dat ik met een potentiele regexp te maken heb ipv dat ik eerst moet achterhalen dat de string een regexp bevat.

[...]

Wat je dus zo in php zou kunnen implementeren?
PHP:
1
2
3
4
5
function x_resume()
{
 static $i = 0;
return ++$i;
}
Of natuurlijk gewoon met een normale klasse.

Maar is het echt verstandig om op zo'n manier de control-structure over meerdere delen van je code te splitsen? Je kan er vast hele krachtige dingen mee doen, maar er bestaan al in de normale syntax voldoende methoden om iig jouw voorbeeld te bereiken. Wat voegt het toe, waarbij het echt beter is om deze aanpak te gebruiken?

Dit is een voorbeeld van een continuation/co-routine/fiber welke je asynchroniteit kan bieden. In mijn voorbeeld wordt er een coroutine object gemaakt eerst, welke bij de eerste resume uitgevoerd wordt. Wanneer het de yield tegenkomt zal het de context van de coroutine opslaan (i.e. local vars van de callstack) en verder gaan waar het de eerste resume was tegengekomen. In mijn geval wordt meteen resume weer aangeroepen een regel erna, wat ervoor doet zorgen dat de coroutine weer uitgevoerd wordt vanaf de yield alleen dan wel MET de opgeslagen context. :-) Met dit soort constructies kan je b.v. een CoroutinePool maken welke non-blocking code kan uitvoeren voor je met veel minder kosten dan dat het je zou kosten als je dit alleen met threads zou doen.

[...]

Bij deze wat puntjes

Domo arigato ^_^

[ Voor 0% gewijzigd door prototype op 06-09-2008 13:41 . Reden: append aan de lijst => opneemt in de map ]

zaterdag 6 september 2008 13:41

Acties:

0 Henk 'm!

user109731

Wel leuk dat functies first-class citizen zijn, dat mis ik echt in PHP. Hoe denken jullie over tuples, lambda-expressies en list comprehensions (als uitbreiding op de [1, 2] syntax) zoals in Haskell en Python?

Klopt het dat een coroutine werkt zoals een generator in oa. Python en JS, behalve dat je een 'doelfunctie' op kunt geven?

Laat maar horen als je (ooit nog) mensen nodig hebt voor code, website, documentatie etc

zaterdag 6 september 2008 13:58

Acties:

0 Henk 'm!

prototype

Cheer Bear

JanDM schreef op zaterdag 06 september 2008 @ 13:41:
Wel leuk dat functies first-class citizen zijn, dat mis ik echt in PHP. Hoe denken jullie over tuples, lambda-expressies en list comprehensions (als uitbreiding op de [1, 2] syntax) zoals in Haskell en Python?

Tuples zouden als syntactisch suiker aangeboden kunnen worden. Zelf was ik erg gecharmeerd van Erlang's pattern matching om hiermee overweg te gaan, dus misschien dat we daar ook nog wat leuks op kunnen bedenken. Lambda expressies (wat imho voor het grootste gedeelte al door de functors behandeld wordt) en list comprehensions zou je in staat stellen om LINQ achtige dingen te realiseren, wat natuurlijk ook super gaaf is. Ik hou me iig van harte aanbevolen als je een leuke syntax erop kan bedenken en een semantische beschrijving erop.

Klopt het dat een coroutine werkt zoals een generator in oa. Python en JS, behalve dat je een 'doelfunctie' op kunt geven?

Yes, je zou er bijvoorbeeld dus ook infinite lists mee kunnen bouwen :-)

Laat maar horen als je (ooit nog) mensen nodig hebt voor code, website, documentatie etc

Will do, voorlopig is het nog even discussieren though. Ik probeer naast m'n werk en studie hier iig wel werk van te maken. Ik heb de ACM article database al leeg zitten halen zo'n beetje

zaterdag 6 september 2008 14:11

Acties:

0 Henk 'm!

MLM

aka Zolo

zeker intressant, en mijn grootste minpunt op Poisyn (newline als statement terminator) is er gelukkig al uit! Verder zie ik typed en untyped variabelen door elkaar, zeker een leuk idee.

Maar ik zie al eea over optimizations (return type inference) staan, mag ik er dan van uit gaan dat de taal gecompiled word? en zo ja, naar wat?

Zeker intressant, zou leuk zijn als dit daadwerkelijk iets word!

-niks-

zaterdag 6 september 2008 14:22

Acties:

0 Henk 'm!

prototype

Cheer Bear

MLM schreef op zaterdag 06 september 2008 @ 14:11:
Maar ik zie al eea over optimizations (return type inference) staan, mag ik er dan van uit gaan dat de taal gecompiled word? en zo ja, naar wat?

Yep. Nou, .oisyn en ik zouden graag een eigen VM willen implementeren. Dus we zouden in eerste instantie misschien onze eigen bytecode instructieset willen hanteren, waarbij het misschien noemenswaardig is dat we voor een stackmachine gaan (eenvoudiger te implementeren uit eigen ervaring, ook al is een registermachine naar alle waarschijnlijkheid sneller, kijk, eerste concessie is al gemaakt hehe). Momenteel zit ik echter me ook in te lezen op LLVM, en het kan ook heel goed zijn dat we een code generator schrijven voor de intermediate representation (IR) van LLVM. Dat heeft veel voordelen in dat je daar gratis compilation (ook JIT) mee krijgt voor verschillende platformen, iets dat we anders zelf zouden moeten coden.

Zeker intressant, zou leuk zijn als dit daadwerkelijk iets word!

Dat zou inderdaad leuk zijn, maar het is niet zozeer het hoofddoel hiervan. Ik ben al meer dan tevreden als ik hier wijzer uit kom. Hoe dan ook denk ik dat het fijn zou zijn als er informatici zijn die eventueel mee zouden willen denken/contributen, aangezien ik denk dat we dit w.s. wel open source willen doen.

[ Voor 6% gewijzigd door prototype op 06-09-2008 14:36 ]

zaterdag 6 september 2008 14:55

Acties:

0 Henk 'm!

RayNbow

Kirika <3

prototype schreef op zaterdag 06 september 2008 @ 13:22:
[...]

func is hier ook een object he? That is, func instanceof Function/Functor. Misschien zouden we er syntactisch suiker voor kunnen bedenken.

Gaarne niet het woord functor gebruiken. Dat zorgt alleen voor verwarring en voordat je het weet heb je Category Theory fundamentalisten achter je aan.

quote: http://www.haskell.org/haskellwiki/Category_theory/Functor
1.5 Functors in Haskell
Properly speaking, a functor in the category Haskell is a pair of a set-theoretic function on Haskell types and a set-theoretic function on Haskell functions satisfying the axioms. However, Haskell being a functional language, Haskellers are only interested in functors where both the object and arrow mappings can be defined and named in Haskell; this effectively restricts them to functors where the object map is a Haskell data constructor and the arrow map is a polymorphic function, the same constraints imposed by the class Functor:
Haskell:
1
2
class Functor f where
  fmap :: (a -> b) -> (f a -> f b)

[...]

Hier verschillen smaken nogal in denk ik. Zelf ben ik de PCRE manier met // suiker onderhand dusdanig gewend dat ik het omgekeerde juist net vindt. Ik heb er daarbij zoals RayNbow ook aankaart liever dat dit op language constructs lijken dan dat we hier de string voor 'misbruiken'. Dit geeft me ook de kans om eventueel optimalisaties uit te voeren tijdens het parsen omdat ik meteen weet dat ik met een potentiele regexp te maken heb ipv dat ik eerst moet achterhalen dat de string een regexp bevat.

Daarnaast kun je ook op een veiligere manier op programmatische manier RegExps of SQL queries bouwen. Denk bijv. aan iets als...

code:

1 2	findCat :: String -> SqlExpr findCat n = \|[$sql\|SELECT * FROM cats WHERE name = $n]\|

> runQuery (findCat "lolcat")
Name: lolcat
Age: 7
Race: Unknown
Sex: Male

NB: Dit is slechts een syntax-voorbeeld in Haskell-style ter illustratie.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

zaterdag 6 september 2008 15:03

Acties:

0 Henk 'm!

prototype

Cheer Bear

RayNbow schreef op zaterdag 06 september 2008 @ 14:55:
[...]

Gaarne niet het woord functor gebruiken. Dat zorgt alleen voor verwarring en voordat je het weet heb je Category Theory fundamentalisten achter je aan.

Urgh, dat zijn de ergsten idd

Nou goed, instances van Function dan

zal de javascripters ook aanspreken denk ik.

Daarnaast kun je ook op een veiligere manier op programmatische manier RegExps of SQL queries bouwen. Denk bijv. aan iets als...
code:
1
2
findCat :: String -> SqlExpr
findCat n = |[$sql|SELECT * FROM cats WHERE name = $n]|
> runQuery (findCat "lolcat")
Name: lolcat
Age: 7
Race: Unknown
Sex: Male
NB: Dit is slechts een syntax-voorbeeld in Haskell-style ter illustratie.

Hmmhmm, in ruby hebben we %q( blaat ) voor 'quasiquotes' (zwakker dan die van haskell welliswaar). Dat zou poisyn eigenlijk ook moeten hebben. Escape sequences zijn niet bepaald leesbaar zeg maar. See below met complexere coroutine voorbeeld.

code:

# Now for a more complex co-routine with bidirectional communication.
# Whatever arguments you pass to Coroutine#resume will be returned by
# Coroutine#yield. The special case here lies in the first invocation
# of resume, where it'll pass its arguments to the closure of the Coroutine.
adder = Coroutine.create function(i) {
    while(true) {
        i++;
        i = Coroutine.yield(i)
    }
}

println(adder.resume(0)) # Prints out 1
println(adder.resume(1)) # Prints out 2
println(adder.resume(7)) # Prints out 8

# (Weak) quasiquotes
%q(Yay, finally no need to escape " or ' anymore! Need to escape \) now though...)

[ Voor 26% gewijzigd door prototype op 06-09-2008 15:10 ]

zaterdag 6 september 2008 16:01

Acties:

0 Henk 'm!

RayNbow

Kirika <3

prototype schreef op zaterdag 06 september 2008 @ 15:03:
[...]

Hmmhmm, in ruby hebben we %q( blaat ) voor 'quasiquotes' (zwakker dan die van haskell welliswaar). Dat zou poisyn eigenlijk ook moeten hebben. Escape sequences zijn niet bepaald leesbaar zeg maar. See below met complexere coroutine voorbeeld.
code:
1
2
3
4
# *snip*

# (Weak) quasiquotes
%q(Yay, finally no need to escape " or ' anymore! Need to escape \) now though...)

Dat zijn denk ik eigenlijk alleen quotations. Quasiquotations stellen je in staat om ook nog te "unquoten" (ookwel: antiquote) en dus terug te springen naar je taal om bijv. de waarde van een variabele op te nemen.

Ik kwam trouwens net nog een artikel tegen over continuations op LtU:
Use Continuations to Develop Complex Web Applications

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

zaterdag 6 september 2008 21:37

Acties:

0 Henk 'm!

prototype

Cheer Bear

drm schreef op zaterdag 06 september 2008 @ 21:20:
Om dit even te koppelen aan prototype's verhaal: Ik denk dat een nieuwe taal helemaal niet helpt. Ik denk dat het veel interessanter is om de beslissers binnen Zend en de PHP dev community te overtuigen van het feit dat dat soort bugs (want het is unexpected behaviour, dat is volgens mij best wel een aardige omschrijving van een bug) eruit moeten.

Je zult hier een hele lastige aan hebben. PHP wordt onderhand zoveel gebruikt dat het niet eenvoudig is om evolutie in de taal te bewerkstelligen zoals RayNbow al heeft aangekaart. PHP zelf als taal zie ik momenteel op heel veel punten broken zijn. Afgezien daarvan wil ik nogmaals onderstrepen dat werken aan de VM mij veel meer interesseert, waarbij ik er wederom bij zeg dat ik de Zend VM slecht ontworpen vindt, op heel veel punten primitief zelfs. Nogmaals, als eenmaal de bytecode instructieset vaststaat zou het helemaal niet onmogelijk moeten zijn om een PHP vertaler te schrijven, zie het zeg maar als een quirksmode op poisyn. Je verliest hierbij dan alleen advanced meuk als continuations, closures etc... (en nee, create_function is __GEEN__ closure potverdikkie

, dat is eval on steroids). Het grote probleem dat hierbij echter komt kijken is de standard library van PHP en zijn modules, en realistisch gezien is dat niet even 1-2-3 zo te implementeren. En als het je al lukt, stel dat je VM threads gaan ondersteunen dan zijn er heel veel modules die niet threadsafe zijn die je niet zomaar even eraan kan vastkoppelen. Dit zijn dus dingen die in PHP ook niet zo 1-2-3 kunnen omdat het ecosysteem het niet zomaar toestaat.

[ Voor 14% gewijzigd door prototype op 06-09-2008 21:40 ]

zaterdag 6 september 2008 22:11

Acties:

0 Henk 'm!

orf

prototype schreef op zaterdag 06 september 2008 @ 21:37:
[...]
Nogmaals, als eenmaal de bytecode instructieset vaststaat zou het helemaal niet onmogelijk moeten zijn om een PHP vertaler te schrijven, zie het zeg maar als een quirksmode op poisyn. Je verliest hierbij dan alleen advanced meuk als continuations, closures etc... (en nee, create_function is __GEEN__ closure potverdikkie , dat is eval on steroids). Het grote probleem dat hierbij echter komt kijken is de standard library van PHP en zijn modules, en realistisch gezien is dat niet even 1-2-3 zo te implementeren. [...]

PHP5.3 Closures en Lambda functies

zaterdag 6 september 2008 22:26

Acties:

0 Henk 'm!

prototype

Cheer Bear

orf schreef op zaterdag 06 september 2008 @ 22:11:
[...]

PHP5.3 Closures en Lambda functies

Ah nice, werd 's tijd ook!

Nu nog continuations, mixins, jit, generational compacting garbage collector (liefst non-conservative, maar ik denk niet dat dat gaat lukken/eenvoudig zal zijn ivm de native bindings), consistentie in de std lib etc...

Edit
Ik kijk net naar hoe closures nu in PHP5.3 zouden moeten zijn, en ik kan niet bepaald zeggen dat ik dat een toffe manier van noteren vindt

PHP:

      $array = array ('lotje', 'mathieu', 'Jaap', 'Kees');
      $filteredElements = array('Jaap', 'Kees');

      $result = array_filter(
              $array,
              function($element) use ($filteredElements)
              {
                      return !in_array($element, $filteredElements);
              }
      );

Closures in andere talen zouden $filteredElements gewoon uit de lexicale context hebben kunnen inferren en binden... use staat daar niet zo lekker, had dan net zo goed een "extern" keyword geintroduceerd want daar doet het me erg aan denken nu

Je moet nu sowiesow eigenlijk al expliciet linkerwerk doen...

code:

1
2
3

function($element) {
extern $filteredElements;
}

Een taal die het bijvoorbeeld uit de lexicale context kan halen is Ruby, zie mijn console sessie:

Ruby:

irb(main):001:0> def foobar
irb(main):002:1> yield
irb(main):003:1> end
=> nil
irb(main):004:0> sjaak = "trekhaak"
=> "trekhaak"
irb(main):005:0> foobar do 
irb(main):006:1* puts sjaak
irb(main):007:1> end
trekhaak
=> nil
irb(main):008:0>

Daarbij vraag ik me ook nog af of de closures in PHP wel closures zijn in de zin dat je de scope binding kunt opvragen en ermee kunt spelen. In Ruby bijvoorbeeld:

Ruby:

def get_binding(param)
    # De volgende regel returned de scope binding van deze methode
    # Daar zit param dus in.
    return binding
end

b = get_binding("hello")
eval("param", b)   #=> "hello"

Ook de motivatie om lambda's te gebruiken vind ik niet bijster sterk. Je gebruikt ze vaak omdat de code daarvan zo simpel is dat je het graag wil 'inlinen'.

P.S. .oisyn, bouw eens syntax highlighting voor Ruby...

[ Voor 71% gewijzigd door prototype op 06-09-2008 22:57 ]

zaterdag 6 september 2008 22:54

Acties:

0 Henk 'm!

PrisonerOfPain

prototype schreef op zaterdag 06 september 2008 @ 22:26:
Closures in andere talen zouden $filteredElements gewoon uit de lexicale context hebben kunnen inferren en binden... use staat daar niet zo lekker, had dan net zo goed een "extern" keyword geintroduceerd want daar doet het me erg aan denken nu Je moet nu sowiesow eigenlijk al expliciet linkerwerk doen...

Het probleem is een beetje dat PHP in dit geval niet zelf kan bepalen of het een variabele is uit de bovenliggende scope, of dat 't een nieuw gedeclareerde variabele moet zijn.

zaterdag 6 september 2008 23:03

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op zaterdag 06 september 2008 @ 22:26:
(liefst non-conservative, maar ik denk niet dat dat gaat lukken/eenvoudig zal zijn ivm de native bindings)

Dit noemde je laatst ook al in een MSN sessie, maar ik zie het probleem niet. .Net heeft ook native bindings (zie bijvoorbeeld de enorm uitgebreide C++ <-> .Net interop in C++/CLI), maar toch een precise GC. Java ondersteunt óók native bindings (zie JNI).

Waar je voor moet zorgen is dat je references aan de native kant ook trackt, en dat je objecten vast kunt zetten op het moment dat er (tijdelijke) native pointers naar zijn (Zie C++/CLI's pin_ptr<> bijvoorbeeld)

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.

zaterdag 6 september 2008 23:19

Acties:

0 Henk 'm!

MLM

aka Zolo

.NET kan het ook idd, maar je moet je wel realiseren dat je als programmer wel wat boekhouding moet overnemen om de GC correct te laten werken. Nadeel van native code is dat je dan wel je native code voor alle platformen van je VM moet ontwikkelen, en ook nog op dezelfde manier aan je scripts moet aanbieden etc... (Aan de andere kant, je hebt niet veel keus natuurlijk, om een database te gebruiken bijvoorbeeld zit je toch waarschijnlijk al vast aan een plugin/library/extension voor elk platform

)

Edit: maybe is het een leuk idee om dit soort dingen op een wiki neer te plempen, want een forumthread op GoT word nogal snel onoverzichtelijk...

[ Voor 12% gewijzigd door MLM op 06-09-2008 23:21 ]

-niks-

zaterdag 6 september 2008 23:24

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op zaterdag 06 september 2008 @ 23:03:
[...]

Dit noemde je laatst ook al in een MSN sessie, maar ik zie het probleem niet. .Net heeft ook native bindings (zie bijvoorbeeld de enorm uitgebreide C++ <-> .Net interop in C++/CLI), maar toch een precise GC. Java ondersteunt óók native bindings (zie JNI).

Waar je voor moet zorgen is dat je references aan de native kant ook trackt, en dat je objecten vast kunt zetten op het moment dat er (tijdelijke) native pointers naar zijn (Zie C++/CLI's pin_ptr<> bijvoorbeeld)

Je bedoelt in de extensions ook de references tracken? Pinnen van objecten voor native pointers heeft wel implicaties voor de garbage collector he? Fragmentation met name, welke je niet goed weg kan coalescen doordat zekere objecten vastgepinned zitten, en je dus niet kan moven.

.oisyn schreef op zaterdag 06 september 2008 @ 23:09:
[...]

Wat PHP wel mist is een mogelijkheid om expliciet nieuwe variabelen te declareren. Dat was voorheen ook niet nodig, omdat variabelen in functies automatisch alleen binnen de functie leven, tenzij je ze als 'global' hebt gemarkeerd. Maar ze hebben al een 'var' keyword, die kunnen ze dan ook hergebruiken in closures om expliciet variabelen te declareren.

Wat ze eventueel ook zouden kunnen doen is net als in andere programmeertalen al gebeurd: gewoon een nieuwe scope maken binnen de huidige scope met curly braces

zaterdag 6 september 2008 23:24

Acties:

0 Henk 'm!

link0007

.oisyn schreef op zaterdag 06 september 2008 @ 23:09:
[...]

Dat is geen probleem. Hetzelfde gaat op in javascript, maar daar werkt het ook. Je zou gewoon kunnen definieren dat alle variabelen waarnaar gerefereerd wordt in de closure en zichtbaar waren op de plek van de definitie van de closure geïmporteerd worden in de scope van de closure.

Wat PHP wel mist is een mogelijkheid om expliciet nieuwe variabelen te declareren. Dat was voorheen ook niet nodig, omdat variabelen in functies automatisch alleen binnen de functie leven, tenzij je ze als 'global' hebt gemarkeerd. Maar ze hebben al een 'var' keyword, die kunnen ze dan ook hergebruiken in closures om expliciet variabelen te declareren.

Wat ik dan veel mooier vind is om net zoals in Pascal structureel je variabelen bij te houden. Zelf declarereer ik m'n variabelen ook nooit van te voren in PHP, maar toch is het in principe even lelijk als midden in een script opeens een require_once te doen: Bestanden die je wenst te includen moet je gewoon van te voren aanhalen (in het begin van het script), niet pas wanneer je er zin in hebt.

Sowieso heb ik het niet zo op de syntax van PHP of andere 'cryptische' talen. BASIC en Pascal zijn veel menselijker en vooral duidelijker. Alhoewel beide talen flinke structurele veranderingen nodig hebben om echt met de 'grote jongens' mee te doen (C++ en consorten) forceren ze wel min of meer degelijke code.

Daarnaast moet gekeken worden naar de functie van een taal: Wil je een beginnerstaal of een taal voor ervaren mensen? Ervaren mensen kan je best PHP geven, die maken er wel wat moois van. Maar juist de beginners kan je beter een humane taal geven die heel erg zeurt voor goede basis-principes.

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;

zaterdag 6 september 2008 23:30

Acties:

0 Henk 'm!

prototype

Cheer Bear

drm schreef op zaterdag 06 september 2008 @ 23:22:
[...]
Dat is kletspraat (nofi). PHP is in de laatste 10 jaar meer geëvolueerd dan welke taal dan ook, dus zeggen dat php niet beinvloedbaar zou zijn is per definitie al niet waar omdat er toch iets of iemand is geweest die die veranderingen heeft bewerkstelligd. Dat het veel gebruikt wordt kan dus zeker niet de reden zijn dat het niet te veranderen is (het werd 5 jaar geleden ook veel gebruikt).

Ik zeg niet dat het niet beinvloedbaar is, ik zeg dat je er een lastige aan zult hebben. Goed voorbeeld, late static binding dat er pas onlangs in zit, de wens om dat te hebben __ZELFS BIJ DE MENSEN VAN ZEND ZELF__ bestaat al 2 jaar! Men wilde het hebben voor de Zend framework iirc, waarbij ze activerecord wilde implementeren zoals Rails dat doet. Het zal vast te doen zijn, maar het is niet makkelijk en anders heb ik ook niet gesteld

[...]
Dat is ook veel leuker dan websites bouwen in PHP, maar desondanks is PHP toch voor heel veel mensen de dagelijkse praktijk. En die dagelijkse praktijk verandert volgens mij niet met een nieuw taaltje (met een suffe naam ), maar met (een aanmoediging van) bijdragen aan dat wat er al is. Dat wil niet zeggen dat je nu moet stoppen met je nieuwe taal, integendeel, hou vol en post hier vooral wat (je) er interessant aan (is/vindt), maar geloof er maar niet dat het de wereld gaat veranderen

Zal ik het voor de goede orde maar nog een keer plaatsen hier?

Mijn intentie:
Ik ben al meer dan tevreden als ik hier wijzer uitkom, zeker als ik ook studiepunten ervoor kan krijgen. De wereld verbeteren doen Ruby en Python al imho

zaterdag 6 september 2008 23:38

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op zaterdag 06 september 2008 @ 23:24:
[...]

Je bedoelt in de extensions ook de references tracken?

Ja, door constructies die aan de VM doorgeven waar die references staan. In C++ kun je dat handig implementeren middels smart pointers. Andere talen hebben wellicht een wat lastigere instrumentatie nodig.

Pinnen van objecten voor native pointers heeft wel implicaties voor de garbage collector he? Fragmentation met name, welke je niet goed weg kan coalescen doordat zekere objecten vastgepinned zitten, en je dus niet kan moven.

Uiteraard, maar objecten moet je dan ook niet voor een langere tijd vastpinnen. In C++/CLI werk je doorgaans direct met 'handles' (bijv. MyClass ^ bla = gcnew MyClass();). Maar je kunt best even het object vastpinnen in het geheugen om bijv. een pointer naar een intern attribuut te verkrijgen, zodat je die aan een native functie kunt voeren. Het is hierbij uiteraard niet de bedoeling dat je 'm voor langere tijd vastpint, en daarom doe je dat ook meestal met een hulpstuk als pin_ptr die je lokaal definieert en het object vrijgeeft op het moment dat de pin uit scope gaat.

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.

zondag 7 september 2008 01:03

Acties:

0 Henk 'm!

drm

f0pc0dert

prototype:
Ik zeg niet dat het niet beinvloedbaar is, ik zeg dat je er een lastige aan zult hebben. Goed voorbeeld, late static binding dat er pas onlangs in zit, de wens om dat te hebben __ZELFS BIJ DE MENSEN VAN ZEND ZELF__ bestaat al 2 jaar! Men wilde het hebben voor de Zend framework iirc, waarbij ze activerecord wilde implementeren zoals Rails dat doet. Het zal vast te doen zijn, maar het is niet makkelijk en anders heb ik ook niet gesteld

Fair enough, 't zal inderdaad niet makkelijk zijn

Maar dat is an sich geen reden om het op voorhand te ontmoedigen.

Zal ik het voor de goede orde maar nog een keer plaatsen hier? Mijn intentie:
Ik ben al meer dan tevreden als ik hier wijzer uitkom, zeker als ik ook studiepunten ervoor kan krijgen. De wereld verbeteren doen Ruby en Python al imho

lol, en ik was al tevreden met php 5.3 (for now ...

)

point taken

edit:

Wezz6400:
(...) we hebben het hier toch niet over een religie?

volgens mij zit je er niet zo heel ver naast

[ Voor 8% gewijzigd door drm op 07-09-2008 01:05 ]

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

zondag 7 september 2008 20:19

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

RayNbow schreef op zaterdag 06 september 2008 @ 12:23:
Je bedoelt dat het gemakkelijker is om een reguliere expressie in een string te stoppen en dan uit te voeren? Een stukje plain text zonder structuur dat pas op het allerlaatst gecheckt wordt of het wel correct is?

Nee, je begrijpt me verkeerd. Ik noemde nog expres javascript er ook bij

Regexpen in de taal integreren vind ik niet zo'n gek idee. Maar perl's impliciete referenties naar allerlei objecten zijn dusdanig ondoorzichtig dat je imho heel erg uit moet kijken met het te sterk overnemen van dit soort dingen uit perl.

Aka, met de manier van javascript bedoel ik dit:

JavaScript:

1
2
3

var r = /^(a+)$/; // of r = new Regexp('/^(a+)$/');
var s = 'aaaa';
var matches = r.exec(s);

in tegen stelling tot perl's nogal onduidelijke constructies waarbij je als beginner maar moet raden hoe je uiteindelijk de captured elementen terug kunt krijgen.

Anderzijds is de vrijheid om dynamisch je regexpen (en sql) aan te kunnen maken regelmatig erg handig. Dus alleen statisch in je taal integreren lijkt me niet de meest handige aanpak als je php wilt vervangen.

IMO is dit eigenlijk net zo evil als eval().

Imho niet, maar het moet natuurlijk wel met mate gebruikt worden. Je kan moeilijk voor elke situatie die zich mogelijk voor kan doen een complete regexp of sql-query in je code verwerken. Soms is het gewoon veel handiger om de boel dynamisch op te bouwen en soms kan je niet anders.

(Programma's moeten structuur hebben, strings missen dat )

Maar soms is het verdraaid handig om dynamisch je gedrag te kunnen bepalen. Zeker bij talen als regexp en sql waar je vrijwel onmogelijk efficient meerdere code-paden in aan kan leggen.

Je kan inderdaad krachtige dingen doen met Continuations: Mobile Continuations for the Web.

Vanuit beveiligingsoogpunt klinkt dat tamelijk eng

prototype schreef op zaterdag 06 september 2008 @ 13:22:
De vraagteken is een valid identifier die men semantisch dient te gebruiken voor predicaten. Het zijn dus gesloten vragen die altijd een true of false opleveren. contains?(o) larger?(a,b) etc... Als men dit consistent gebruikt in de taal kan men aan de functie/methodenaam zelf al zien wat deze b.v. zou moeten returnen (een boolean). Ik kan me wel vinden in je punt dat dit misschien tot verwarring kan leiden met de ternary if-else.

Mja, je naamgeving is - als het goed is - toch al zodanig dat je een ja of nee antwoord verwacht natuurlijk.
Maar print(object.contains?(key) ? 'heeft em' : 'heeft em niet'); is toch wat raar lezen

Hmmm, misschien zouden we pattern matching in de taal moeten hebben zoals Erlang dit ook heeft om hier ook syntactisch suiker voor aan te kunnen bieden.

Ik vind ook hier de manier van javascript wel handig.

Op welke regel doel je precies?
De eerste regel is een hashmap maken met keys :foo en :dude, die respectievelijk naar "bar en "sweet" mappen.

Op regels 127 t/m 129:

code:

1
2
3

symbol = :foo
a = :foo
b = :foo

func is hier ook een object he? That is, func instanceof Function/Functor. Misschien zouden we er syntactisch suiker voor kunnen bedenken.

In javascript kan het iig ook.

Hier verschillen smaken nogal in denk ik. Zelf ben ik de PCRE manier met // suiker onderhand dusdanig gewend dat ik het omgekeerde juist net vindt. Ik heb er daarbij zoals RayNbow ook aankaart liever dat dit op language constructs lijken dan dat we hier de string voor 'misbruiken'. Dit geeft me ook de kans om eventueel optimalisaties uit te voeren tijdens het parsen omdat ik meteen weet dat ik met een potentiele regexp te maken heb ipv dat ik eerst moet achterhalen dat de string een regexp bevat.

Zie hierboven. Alleen maar een taal-integratie bieden waarbij je eigenlijk niet meer dynamisch de boel samen kan stellen beperkt je toch in diverse plaatsen wel aardig. Ik weet iig dat wij op een aantal plaatsen dmv string-concattenation regexps in elkaar klussen. Hoewel die dan over het algemeen niet al te complex zijn (bijv. een zoekterm voor de highlighting er in plakken).

Bovendien denk ik dat je er verstandig aan doet om iets duidelijker te zijn in wat je code doet, ipv de perl-manier te pakken (geen idee waar jij hem verder van afgeleid hebt). Althans, ik denk dat het duidelijker kan dan dit:

Perl:

$s = 'aaaa';
$s =~ /a+/; # returns true, aka leaves $s unchanged
$s =~ s/a+/b/; # alters $s to contain 'b'
$s =~ tr/a/b/; # replaces every a with b in $s

zondag 7 september 2008 21:10

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op zaterdag 06 september 2008 @ 13:22:
De vraagteken is een valid identifier die men semantisch dient te gebruiken voor predicaten. Het zijn dus gesloten vragen die altijd een true of false opleveren. contains?(o) larger?(a,b) etc... Als men dit consistent gebruikt in de taal kan men aan de functie/methodenaam zelf al zien wat deze b.v. zou moeten returnen (een boolean). Ik kan me wel vinden in je punt dat dit misschien tot verwarring kan leiden met de ternary if-else.

Niet alleen verwarring, ook lex problemen

code:

1	a = b?c:d;

Is het eerste token na de '=' nou 'b' of 'b?c'

Overigens, mijn preliminaire voorstel: http://oisyn.nl/proton/proton.html
Met de voetnoot dat het nog enums mist, en ik wil tuples eigenlijk ook op kunnen slaan in vars.

Over het opnemen van SQL heb ik na zitten denken, maar ik vond dat onpraktisch omdat de SQL syntax nogal aan verandering onderhevig is en vaak niet geheel compatible is tussen verschillende DBMS'en.

[ Voor 16% gewijzigd door .oisyn op 07-09-2008 21:13 ]

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.

zondag 7 september 2008 22:02

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op zondag 07 september 2008 @ 21:10:
[...]

Niet alleen verwarring, ook lex problemen
code:
1
a = b?c:d;
Is het eerste token na de '=' nou 'b' of 'b?c'

Nee, ? is alleen toegestaan als __trailing__ identifier. Oftewel, indien het gebruikt wordt voor een identifier, dan moet het de laatste karakter zijn. Geen lex probleem dus, in dit geval zou je met een backtrace kunnen inferren dat bij tegenkomst van een ':', de ? de token is zoals je 'm zou verwachten bij een ternary conditional. Het maakt het niet eenvoudig met parsen mbt de : voor symbols/lightweight strings, dus ik stel voor dus om idd de ? maar te schrappen als valid trailing identifier.

In je voorstel zie ik trouwens de mogelijkheid tot interfaces en ook open classes. Hoe sta je tegenover class_eval/instance_eval methodes, waardoor je dus tijdens runtime de interface kan aanpassen van een class/object? Dat lijkt me niet een onredelijk iets om te hebben in een dynamische taal. Het zorgt er imho echter wel voor dat interface foo {} niet meer nuttig is aangezien je de interface al tijdens runtime helemaal kan aanpassen (een van de redenen ook waarom er in Javascript b.v. geen interfaces zitten omdat je de prototypes van "klassen" kan aanpassen tijdens runtime")

Over het opnemen van SQL heb ik na zitten denken, maar ik vond dat onpraktisch omdat de SQL syntax nogal aan verandering onderhevig is en vaak niet geheel compatible is tussen verschillende DBMS'en.

Wat dacht je van setcomprehension ter aanvulling op plain SQL? Voorbeeld: "SELECT u.name FROM Users u, Groups g WHERE u.gid = g.id AND u.id >= 0 AND u.id < 9999" <=>

code:

1	foo = { Users u, Groups g \| u.gid = g.id && u.id >= 0 && u.id < 9999 @ u.name }

De setcomprehension zou hierbij dus als abstractie eventueel kunnen dienen. Wat er staat doet denk ik menig persoon wel denken aan LINQ notatie (alleen dat dat dan sequence based is, een specialisatie op een set dus). Zelf denk ik dat niet veel mensen dit zullen gebruiken dus ik zou m'n voorstel ook direct weer in willen trekken ;-) en denk ik dat quotations gewoon zullen werken. Of quasiquotes ala Haskell.

@ACM:

Zie hierboven. Alleen maar een taal-integratie bieden waarbij je eigenlijk niet meer dynamisch de boel samen kan stellen beperkt je toch in diverse plaatsen wel aardig. Ik weet iig dat wij op een aantal plaatsen dmv string-concattenation regexps in elkaar klussen. Hoewel die dan over het algemeen niet al te complex zijn (bijv. een zoekterm voor de highlighting er in plakken).

Een aantal voorstellen:

code:

r = new RegEx("/^haiz$/");
r = "/^haiz$/".to_regex

# We just reopen the String class and mixin the RegEx module.
r = "/^haiz$/".match("haiz")

Wbt die assignments, dat waren gewoon een paar arbitrare assignments van lightweight strings naar vars. Het gaat erom dat al die vars iig refereren naar hetzelfde flyweight string object. Agreed mbt de semantiek beschrijven van de regexps.

[ Voor 82% gewijzigd door prototype op 08-09-2008 01:05 ]

zondag 7 september 2008 22:12

Acties:

0 Henk 'm!

RayNbow

Kirika <3

ACM schreef op zondag 07 september 2008 @ 20:19:
[...]

Nee, je begrijpt me verkeerd. Ik noemde nog expres javascript er ook bij

Ja, maar ik wist dus niet dat JavaScript een alternatieve syntax ondersteunde.

Anderzijds is de vrijheid om dynamisch je regexpen (en sql) aan te kunnen maken regelmatig erg handig.

Het gebruik van concrete syntax wil niet zeggen dat alles statisch moet zijn. Je kan ook nog escape mogelijkheden (=antiquote) aanbieden aan de programmeur. Zie bijv. het kunstmatige voorbeeld onderaan deze post van mij.

Of zie bijv. de feature van VB9, XML literals:

code:

' Statisch
Dim Person = <Person Dept="SQL Server">
                  <Name>Erik Meijer</Name>
             </Person>

Console.WriteLine(Person.Name)
Console.WriteLine(Person.Element("Name"))

' Dynamisch
Dim name = "Erik Meijer"
Person = <Person Dept="SQL Server">
              <Name><%= name %></Name>
         </Person>

Console.WriteLine(Person.Name)
Console.WriteLine(Person.Element("Name"))

[...]

Imho niet, maar het moet natuurlijk wel met mate gebruikt worden. Je kan moeilijk voor elke situatie die zich mogelijk voor kan doen een complete regexp of sql-query in je code verwerken. Soms is het gewoon veel handiger om de boel dynamisch op te bouwen en soms kan je niet anders.

Ja, maar het is veel mooier om een regexp/sql-query/whatever te kunnen quoten en te kunnen escapen (=antiquoten) dan het concateneren van wat strings.

Paper: Why It's Nice to be Quoted: Quasiquoting for Haskell

[...]

Vanuit beveiligingsoogpunt klinkt dat tamelijk eng

Tuurlijk, je moet niet alles slikken wat de client naar je toe stuurt.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

maandag 8 september 2008 00:34

Acties:

0 Henk 'm!

MLM

aka Zolo

even op .oisyn's pagina gekeken, wat me zo snel opvalt:
waarom zou je een long als type opnemen? waarom de boel weer ingewikkelder maken door de aanwezigheid van meerdere types integers (signed/unsigned/32b/64b)

is het char type een unicode type, en een String een unicode string?

code:

1
2
3

string s1;
string s2 = new;
string s3 = new("literal!");

wat houd dat in voor s1? is dat een null-reference? of is dat een default-constructed string ("")?
sowieso, de aanwezigheid van het keyword "string" maar het is geen first-class type?

kan je stellen dat typeof<int[4,5]> == typeof<int[4][5]>? misschien het overwegen waard in elk geval (je kan altijd nog een .row(idx) en een .column(idx) member maken om een lagere rank array eruit te vissen)

ik vind de Lua manier van multiple return values wel duidelijk dan de angular bracket notatie:
function foo(arg1, arg2) : var, int, string
auto a, b, c = foo(42, "x");
(in zoverre dat, ik zie geen probleem in de angular brackets weg te laten, het blijft leesbaar)

maar, het blijft intressante materie!

-niks-

maandag 8 september 2008 01:03

Acties:

0 Henk 'm!

prototype

Cheer Bear

Liever type inference dan heletijd de declarative type erbij te moeten zetten om eerlijk te zijn. Declarative type intikken wears down my fingers

. En ook al niet heletijd var

Waarom kunnen we niet alles standaard gewoon een 'var'-type laten zijn (zonder dat ik een var qualifier hoef op te geven), en dat je mensen de keuze moet geven om een declarative type te geven (waaraan ook strict op gecontroleerd wordt, i.e. je mag alleen maar objecten aan die var binden die van dat type zijn). Verder vind ik dat long er ook uit moet en dat we 't gewoon moeten houden op Integer, die bij overflow zelf scaled naar een grotere capacity

maandag 8 september 2008 03:07

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

MLM schreef op maandag 08 september 2008 @ 00:34:
even op .oisyn's pagina gekeken, wat me zo snel opvalt:
waarom zou je een long als type opnemen?

Hence het vraagteken erachter, ik was er ook niet helemaal zeker van

. Alleen een int is imho prima, die dan doorgaans gewoon 64 bits is (wat hedendaagse processoren ook gewoon zijn), of het gewoon niet definieren dat het 64 bits is maar van de implementatie af laten hangen. Live upscalen ben ik geen voorstander van, dat geeft denk ik teveel performance impact bij het doen van berekeningen.

is het char type een unicode type, en een String een unicode string?

Er bestaat niet zoiets als een unicode string. Wellicht kun je stellen dat alle unicode codepoints in de string kunnen staan, maar dan weet je nog niets. Is ie UTF-8, UTF-16 of simpelweg UCS-4? Of een andere encoding die alle unicode codepoints kan representeren? Verder denk ik niet dat het van belang is te definieren hoe de string z'n data opslaat - dat is namelijk een VM detail. Zolang er maar gewoon functies zijn om 'm te converteren van en naar specifieke encodings. Wat dat betreft denk ik nu eigenlijk dat ik wel een datatype voor 'byte' toe moeten voegen, zodat je gewoon binaire data kunt representeren middels arrays van bytes.

Voor een char is het daadwerkelijk wel interessant. Dat moet mijn inziens wel echt 1 teken zijn, en niet een halve oid. De gewone binaire waarde van de unicode codepoint lijkt me dus wel handig, een char is dus gewoon een int.

code:
1
2
3
string s1;
string s2 = new;
string s3 = new("literal!");
wat houd dat in voor s1? is dat een null-reference? of is dat een default-constructed string ("")?
sowieso, de aanwezigheid van het keyword "string" maar het is geen first-class type?

Hier zat ik nog over te twijfelen (first-class is overigens niet een correcte term ervoor - een string is namelijk ook een first-class citizen in Java of C#, ookal gedragen ze zich niet als een primitive). Voor de keuze om string wel een keyword te maken ook al zou het geen first-class type zijn kan ik je verwijzen naar C#. String bevindt zich als normale class namelijk gewoon in een namespace (overigens ook nog iets dat beschreven moet worden, ik wil wel namespaces ondersteunen), en er is geen reden waarom je de identifier 'String' niet voor heel iets anders in een bepaalde scope kunt gebruiken. Het keyword 'string' echter verwijst altijd het juiste ding.

Maar idd, waar ik over zat te denken is idd om het een valuetype te laten zijn, net als andere primitives. En dan met autoboxing naar objects, net als voor int en float etc.

kan je stellen dat typeof<int[4,5]> == typeof<int[4][5]>? misschien het overwegen waard in elk geval (je kan altijd nog een .row(idx) en een .column(idx) member maken om een lagere rank array eruit te vissen)

Nee, dat is het niet, en dat vind ik ook niet het overwegen waard. Als het dat wel was dan zou int[,] überhaupt geen bestaansrecht hebben, dus waar het om gaat is wat een multidimensionale array toevoegt boven arrays van arrays. Ik ben van mening dat multidimensionale arrays de betere datastructuur zijn als je het echt over multidimensionale data hebt. Neem bijv. een plaatje. In een taal als Java, waar multidimensionale arrays niet bestaan, of in een taal als C++ waar alle dimensies behalve de hoogste compile-time constants moeten zijn, worden die gerepresenteerd door 1D arrays omdat zij een contiguous representatie bieden, en de programmeur mag dan zelf vogelen met y*width+x om de index van een pixel op (x,y) uit te rekenen. In C++ biedt boost::multi_array op zich uitkomst, en C# ondersteunt gewoon native multidimensional arrays. Ik vind dat een dergelijk datatype bestaansrecht heeft.

Eventueel zou je views op dezelfde data kunnen maken. Stel je hebt 64 ints achter elkaar in het geheugen staan. Dat zou een array van 64 ints kunnen zijn, of eentje van bijv. 43 ints ergens in het midden. Of juist een 2D array van 8x8 ints. En als je het als een array van 8x8 ziet, dan kun je daar ook een 4x4 slice uit halen door aan beide kanten de buitenste twee rijen en kolommen weg te denken.

Dat werkt dan ook niet meer als het jagged arrays zijn, want dat impliceert dat je een willekeurige rij kunt herassignen:

code:

1 2	var x[][] = new var[4][4]; var[2] = new var[123];

ik vind de Lua manier van multiple return values wel duidelijk dan de angular bracket notatie:
function foo(arg1, arg2) : var, int, string
auto a, b, c = foo(42, "x");
(in zoverre dat, ik zie geen probleem in de angular brackets weg te laten, het blijft leesbaar)

Beetje ambigu. Doorgaans betekent bovenstaande notatie dat a en b ongeïnitialiseerd moeten blijven, en dat c wordt geïnitialiseerd met foo(42, "x")

[ Voor 10% gewijzigd door .oisyn op 08-09-2008 03:15 ]

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.

maandag 8 september 2008 09:45

Acties:

0 Henk 'm!

MLM

aka Zolo

.oisyn schreef op maandag 08 september 2008 @ 03:07:
[...]
Hence het vraagteken erachter, ik was er ook niet helemaal zeker van . Alleen een int is imho prima, die dan doorgaans gewoon 64 bits is (wat hedendaagse processoren ook gewoon zijn), of het gewoon niet definieren dat het 64 bits is maar van de implementatie af laten hangen. Live upscalen ben ik geen voorstander van, dat geeft denk ik teveel performance impact bij het doen van berekeningen.

True, als iemand ooit een hogere int dan 2^64-1 wilt gebruiken, kan je altijd nog een BigInt class oid beschikbaar maken. Ik kan alleen uit C++ ervaring spreken, maar ik kom zelden in aanraking met de limiet van een 32b int, laat staan een 64b int.

Er bestaat niet zoiets als een unicode string. Wellicht kun je stellen dat alle unicode codepoints in de string kunnen staan, maar dan weet je nog niets. Is ie UTF-8, UTF-16 of simpelweg UCS-4? Of een andere encoding die alle unicode codepoints kan representeren? Verder denk ik niet dat het van belang is te definieren hoe de string z'n data opslaat - dat is namelijk een VM detail. Zolang er maar gewoon functies zijn om 'm te converteren van en naar specifieke encodings. Wat dat betreft denk ik nu eigenlijk dat ik wel een datatype voor 'byte' toe moeten voegen, zodat je gewoon binaire data kunt representeren middels arrays van bytes.

Voor een char is het daadwerkelijk wel interessant. Dat moet mijn inziens wel echt 1 teken zijn, en niet een halve oid. De gewone binaire waarde van de unicode codepoint lijkt me dus wel handig, een char is dus gewoon een int.

Tuurlijk zijn er wel dingen als een unicode string, alleen zijn ze over het algemeen transparant voor de gebruiker.
Los daarvan, is UCS-4 niet echt overkill? De hoeveelheid tekens die buiten UTF-16 valt, en gebruikt word, is echt minimaal. Vergeet niet dat in de meeste web-scripts strings ongeveer de meest voorkomende objecten zijn, en 2x zo hoge memory requirements kan best gaan optellen...

Hier zat ik nog over te twijfelen (first-class is overigens niet een correcte term ervoor - een string is namelijk ook een first-class citizen in Java of C#, ookal gedragen ze zich niet als een primitive). Voor de keuze om string wel een keyword te maken ook al zou het geen first-class type zijn kan ik je verwijzen naar C#. String bevindt zich als normale class namelijk gewoon in een namespace (overigens ook nog iets dat beschreven moet worden, ik wil wel namespaces ondersteunen), en er is geen reden waarom je de identifier 'String' niet voor heel iets anders in een bepaalde scope kunt gebruiken. Het keyword 'string' echter verwijst altijd het juiste ding.

Maar idd, waar ik over zat te denken is idd om het een valuetype te laten zijn, net als andere primitives. En dan met autoboxing naar objects, net als voor int en float etc.

Behalve built-in types, heeft de gebruiker de mogelijkheid om nieuwe valuetypes te definieren? Ik zie geen enum/struct/union achtige mogelijkheden?

Nee, dat is het niet, en dat vind ik ook niet het overwegen waard. Als het dat wel was dan zou int[,] überhaupt geen bestaansrecht hebben, dus waar het om gaat is wat een multidimensionale array toevoegt boven arrays van arrays. Ik ben van mening dat multidimensionale arrays de betere datastructuur zijn als je het echt over multidimensionale data hebt. Neem bijv. een plaatje. In een taal als Java, waar multidimensionale arrays niet bestaan, of in een taal als C++ waar alle dimensies behalve de hoogste compile-time constants moeten zijn, worden die gerepresenteerd door 1D arrays omdat zij een contiguous representatie bieden, en de programmeur mag dan zelf vogelen met y*width+x om de index van een pixel op (x,y) uit te rekenen. In C++ biedt boost::multi_array op zich uitkomst, en C# ondersteunt gewoon native multidimensional arrays. Ik vind dat een dergelijk datatype bestaansrecht heeft.

Ik vind het persoonlijk verwarrend, juist omdat je nu 3 types arrays hebt:
1. arr[x]
2. arr[x,y]
3. arr[x][y]
Terwijl je er in principe met 1 genoeg hebt:
- arr[x][y]
Enige nadeel waar ik zo op kom is dat je mogelijk meer overhead hebt voor multidim arrays, omdat je de metadata (aantal dimensies, aantal elementen) per array opslaat, en een array of array dus die metadata meerdere keren bevat. Een lookup van een waarde word dan N lookups (N=rank), itt N multiply-adds, niet echt noemenswaardig imo. Voordeel van 1 type array is overzichtelijkheid, simpelere types en minder implementatie-tijd.

Vergeet niet dat 1 van de voordelen van PHP de lage instapdrempel is. Een PHPer heeft geen last van square brackets voor de declaratie van een array, hij gebruik gewoon $arr = array(); Als je daadwerkelijk een superieure oplossing wilt bedenken, vergeet dan niet dat niet iedereen die PHP gebruikt een achtergrond uit meerdere programmeertalen heeft, en de gemiddelde tweaker die dit leest juist wel...

Eventueel zou je views op dezelfde data kunnen maken. Stel je hebt 64 ints achter elkaar in het geheugen staan. Dat zou een array van 64 ints kunnen zijn, of eentje van bijv. 43 ints ergens in het midden. Of juist een 2D array van 8x8 ints. En als je het als een array van 8x8 ziet, dan kun je daar ook een 4x4 slice uit halen door aan beide kanten de buitenste twee rijen en kolommen weg te denken.

Dat werkt dan ook niet meer als het jagged arrays zijn, want dat impliceert dat je een willekeurige rij kunt herassignen:
code:
1
2
var x[][] = new var[4][4];
var[2] = new var[123];

So? als je type een var[][] is, staat niet vast welke dimensies hij heeft. Dat je hem initialiseert als [4][4] betekent niet dat ie dat moet blijven. Tuurlijk, ik zie niet gelijk het nut van om je mooie 2D array te misvormen, maar dat het kan betekend niet dat het moet.
In jouw voorbeeld zou ik misschien wel een rij willen toevoegen, doe je dan:

code:

1
2
3

var x1[][] = new var[4][4]; //Origineel
var x2[][] = new var[4][5]; //Met extra rij
for(int i = 0; i < 4; i ++) copy_array(x1[i], x2[i]);

of zeg je

code:

1
2
3

var x1[][] = new var[4][4]; //Origineel
var x2[][] = x1;
x2.add_row();

Of supporten arrays helemaal geen growing?

Beetje ambigu. Doorgaans betekent bovenstaande notatie dat a en b ongeïnitialiseerd moeten blijven, en dat c wordt geïnitialiseerd met foo(42, "x")

In C wel ja. Dat betekent niet dat jij dat ook moet doen

Mag je in de huidige incarnatie wel dit doen:

code:

1
2
3

function foo() : <var, var, var> //impl
var x, y, z;
<x, y, z> = foo();

samenvoegen naar:

code:

1	var <x, y, z> = foo();

Dat is juist wat ik mooi vind

btw, dit is als opbouwende kritiek bedoeld, niet als flame

-niks-

maandag 8 september 2008 12:03

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

MLM schreef op maandag 08 september 2008 @ 09:45:
[...]

True, als iemand ooit een hogere int dan 2^64-1 wilt gebruiken, kan je altijd nog een BigInt class oid beschikbaar maken.

Bignum staat er bij

Ik kan alleen uit C++ ervaring spreken, maar ik kom zelden in aanraking met de limiet van een 32b int, laat staan een 64b int.

Ik regelmatig

Tuurlijk zijn er wel dingen als een unicode string, alleen zijn ze over het algemeen transparant voor de gebruiker.

Nee, je hebt encodings en je hebt unicode codepoints. Wellicht dat jouw definitie van een unicode string een string is met een standaard unicode encoding, maar er bestaat niet zoiets als "deze data is unicode" oid, en dat is een veelgemaakte vergissing.

Los daarvan, is UCS-4 niet echt overkill?

Ik zei geloof ik expliciet dat ik niet ging definieren hoe de implementatie was

Behalve built-in types, heeft de gebruiker de mogelijkheid om nieuwe valuetypes te definieren? Ik zie geen enum/struct/union achtige mogelijkheden?

enum noemde ik al in mijn post, union vind ik geen toegevoegde waarde hebben (zeker niet in deze context), en value types wil ik idd ook nog wel toevoegen, wat dan in feite gewoon classes zijn met value semantics (dus copy on assign)

Ik vind het persoonlijk verwarrend, juist omdat je nu 3 types arrays hebt:
1. arr[x]
2. arr[x,y]
3. arr[x][y]
Terwijl je er in principe met 1 genoeg hebt:
- arr[x][y]

Ik snap even niet waarom je hier arr[x] ook nog expliciet noemt (je hebt immers maar 2 "2d" arrays - eentje met vaste dimensies via arr[x,y] en een jagged variant waarbij de data per rij all over the place kan staan), maar ik vind het persoonlijk niet verwarrend, en ik vind het heerlijk dat bijv. .Net ook dat onderscheid kent, en ik mis het in Java en er is een reden waarom er C++ container templates voor bestaan. Waarom denk je dat ze in Java pixeldata steevast met int[] definieren, en niet met int[][], terwijl het toch echt gewoon 2D data is?

So? als je type een var[][] is, staat niet vast welke dimensies hij heeft. Dat je hem initialiseert als [4][4] betekent niet dat ie dat moet blijven. Tuurlijk, ik zie niet gelijk het nut van om je mooie 2D array te misvormen, maar dat het kan betekend niet dat het moet.

Als het moet gebruik je jagged arrays omdat je rijen dan niet even lang hoeven zijn. Als je echt 2D data hebt met een vaste lengte en breedte gebruik je een 2D array (die je natuurlijk óók kunt resizen, maar je kunt niet 1 rij null maken of heralloceren)

In jouw voorbeeld zou ik misschien wel een rij willen toevoegen, doe je dan:
code:
1
2
3
var x1[][] = new var[4][4]; //Origineel
var x2[][] = new var[4][5]; //Met extra rij
for(int i = 0; i < 4; i ++) copy_array(x1[i], x2[i]);
of zeg je
code:
1
2
3
var x1[][] = new var[4][4]; //Origineel
var x2[][] = x1;
x2.add_row();
Of supporten arrays helemaal geen growing?

Bij dit stukje krijg ik een beetje het idee dat je niet helemaal snapt hoe jagged arrays werken, grammatisch gezien. var[] is een array type. Je kunt natuurlijk een array van arrays maken, door elk element een var[] te laten zijn. Dit betekent dat het "buitenste" type een var[][] is. Dat betekent niet dat dat ineens een 2d array is. Het betekent gewoon dat elk element in de array toevallig ook een array is. Uiteraard van verschillende grootten en ze kunnen zelfs evt. null zijn. Een add_row() vind ik dan ook een rare naamgeving, want x1 is een array, en dus ondersteunt het alle properties en methods die voor elke array gelden. Een add_row() op een 1D array (wat x1 net zo goed kon zijn als het element-type bijv. int was ipv een int[]) vind ik onzinnig - 'row' heeft alleen maar betekenis in de 2D variant.

Wellicht helpt het als je het zo ziet:

code:

typedef int ElementA;
typedef int[] ElementB;

ElementA[] arr1;
ElementB[] arr2;

arr1 en arr2 zijn beide 1D arrays. Het enige verschil tussen de twee types is dat de elementen van arr2 toevallig zelf ook arrays zijn. arr2 weet verder niets over de eigenschappen van z'n elementen, dus je kunt bijv. z'n breedte niet opvragen omdat die wordt gedefinieerd door de elementen zelf. Bovendien staat die breedte dus niet vast, omdat elk element in arr2 zijn eigen lengte kan hebben. En voor arr1 heeft het concept "breedte" weer helemaal geen betekenis.

In C wel ja. Dat betekent niet dat jij dat ook moet doen

Dat betekent dat idd niet ja, maar er is natuurlijk een reden waarom alle C-family talen het zo doen.

code:

int a = foo();  // duidelijk, maar 1 variabele
int a, b; // duidelijk, 2 variabelen ongeïnitialiseerd
int a = 1, b = 2; // duidelijk, 2 variabelen geïnitialiseerd
int a, b = 2; // a ongeïnitialiseerd, b geïnitialiseerd
int a, b = foo(); // en nu? Wat als foo() 1 int returnt? En wat als ie 2 ints returnt?

Ik vind het dus gewoon verwarrend, en er moet dus imho iets omheen om de variabelen te groeperen. Of je dat nou doet met <...> of met (...) is mij verder om het even. Ik zat er overigens aan te denken om het maar (...) te maken, want het mooie daarvan is is dat er dan geen verschil meer is tussen een tuple van 1 expressie en gewoon een expressie.

Mag je in de huidige incarnatie wel dit doen:
code:
1
2
3
function foo() : <var, var, var> //impl
var x, y, z;
<x, y, z> = foo();
samenvoegen naar:
code:
1
var <x, y, z> = foo();
Dat is juist wat ik mooi vind

Dat vind ik idd ook mooier, dus ja

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.

maandag 8 september 2008 15:38

Acties:

0 Henk 'm!

roy-t

Ik heb nog een klein naamgeving dingetje te zeuren:

public static function foo() {
# Needless to say, this string will be interned.
return "I am a static method!"
}

/**
* Instance method that will be mixed in
* with a class that includes this module
*/
public function contains?(Object o) {
return this.collection.contains(o)

Zelfs in de comments zeg je al "static method" op school leert iedereen method, volgens OO heeft het method, waarom dan toch "public static function foo()" en niet het mooiere/logischere "public static method foo()"?

Waarom iets anders noemen dan dat het heet?

~ Mijn prog blog!

maandag 8 september 2008 15:44

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Ik denk dat jouw definities niet helemaal kloppen. Een method is óók een function (maar een function niet per definitie een method). Dus de naamgeving is niet fout, en het is een beetje loos om de taal te compliceren met extra keywords. Daarnaast is het onhandig bij refactoring (je kunt een static method niet makkelijk naar buiten verplaatsen of andersom).

Of moeten we functies die een bool returnen ook maar gewoon predicates noemen? Of functies die niets returnen procedures (Basic doet dit bijvoorbeeld)?

[ Voor 17% gewijzigd door .oisyn op 08-09-2008 15:47 ]

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.

maandag 8 september 2008 16:00

Acties:

0 Henk 'm!

supakeen

Oeh iets dat ik heel graag in jullie poisyn zou willen zien (ik stel voor om een drie letter afkorting te maken

) is de manier waarop Python werkt met lists, strings en andere datatypen. Dat houdt het volgende in voor een string. (Schaamteloze plug uit de interpreter

)

code:

>>> string = "foo bar"
>>> string[0]
'f'
>>> string[:1]
'f'
>>> string[:2]
'fo'
>>> string[:-1]
'foo ba'
>>> string[1:-1]
'oo ba'
>>> string[-1:]
'r'

Scheelt bergen

maandag 8 september 2008 16:06

Acties:

0 Henk 'm!

RayNbow

Kirika <3

.oisyn schreef op maandag 08 september 2008 @ 15:44:
Of moeten we functies die een bool returnen ook maar gewoon predicates noemen? Of functies die niets returnen procedures (Basic doet dit bijvoorbeeld)?

Ik stel het HOF^** keyword voor voor dat lijstje

.

(**Higher Order Function)

Charlie Murphy schreef op maandag 08 september 2008 @ 16:00:
Oeh iets dat ik heel graag in jullie poisyn zou willen zien (ik stel voor om een drie letter afkorting te maken ) is de manier waarop Python werkt met lists, strings en andere datatypen. Dat houdt het volgende in voor een string. (Schaamteloze plug uit de interpreter )
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
>>> string = "foo bar"
>>> string[0]
'f'
>>> string[:1]
'f'
>>> string[:2]
'fo'
>>> string[:-1]
'foo ba'
>>> string[1:-1]
'oo ba'
>>> string[-1:]
'r'
Scheelt bergen

Slices?

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

maandag 8 september 2008 16:14

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Charlie Murphy schreef op maandag 08 september 2008 @ 16:00:
Oeh iets dat ik heel graag in jullie poisyn zou willen zien

Hey, mijn voorstel heette "proton", geen "poisyn"

Ik zat zelf nog te denken aan PINP: PINP Is Not PHP

(ik stel voor om een drie letter afkorting te maken ) is de manier waarop Python werkt met lists, strings en andere datatypen.

Ik noemde al views op arrays. Dit zou op zich ook voor strings kunnen gelden, of voor custom containers. Ik zal het in de volgende draft opnemen

.

De vraag hierbij is wel: wil je een kopie, of wil je een referentie? Voor substrings wil je meestal wel een kopie. Maar voor views op arrays wil je vaak juist een referentie.

[ Voor 13% gewijzigd door .oisyn op 08-09-2008 16:17 ]

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.

maandag 8 september 2008 16:36

Acties:

0 Henk 'm!

supakeen

Ik zou dat graag terug willen zien in een referentie juist voor die arrays.

Als ik array[1:-1] = [5,6] doe wil ik dat de elementen worden vervangen. In het geval van een string het liefst hetzelfde zodat ik dingen kan wijzigen binnen een string. Python doet dat helaas niet voor string objects aangezien die immutable zijn.

Verder gaat in jullie taal alles een object worden? Of zoveel mogelijk? Dus ook standaard string methods etc.

[ Voor 4% gewijzigd door supakeen op 08-09-2008 16:41 ]

maandag 8 september 2008 16:43

Acties:

0 Henk 'm!

writser

Maak er dan P.I.M.P van

. Veel respect voor dit project, een nieuwe taal construeren is geen laffe onderneming. Ik ga het in de gaten houden. Als ik jullie was zou ik inderdaad gebruik maken van LLVM, zoals dat al ergens in het topic is beschreven. Kun je veel leuke dingen mee doen, de code is duidelijk en het is een actief project.

Ik denk dat de meeste mensen wel een alternatief zouden willen gebruiken als de leercurve voor ze niet (te) hoog ligt

Maar waarom zou ik dit gebruiken in plaats van PHP? Ik zie hier een mengeling tussen python en php ontstaan maar ik mis nog wat "killer features". Het lijkt mij veel interessanter om een taal te ontwerpen die in een aantal opzichten revolutionair is, bijvoorbeeld:

- enorm eenvoudige ondersteuning voor threading
- de scripttaal kan draaien (of delen laten draaien) op GPU's
- ingebouwde ondersteuning voor databases

Om eens wat voorbeelden uit mijn duim te zuigen. Helemaal als je er studiepunten mee moet verdienen lijkt zo'n project me interessanter. Inner classes, tupels, en default arguments dat kan je later nog wel toevoegen

. Of is het gewoon je/jullie bedoeling om PHP op een aantal punten te verbeteren?

[ Voor 9% gewijzigd door writser op 08-09-2008 16:45 ]

Onvoorstelbaar!

maandag 8 september 2008 16:43

Acties:

0 Henk 'm!

prototype

Cheer Bear

Charlie Murphy schreef op maandag 08 september 2008 @ 16:36:
Ik zou dat graag terug willen zien in een referentie juist voor die arrays.

Als ik array[1:-1] = [5,6] doe wil ik dat de elementen worden vervangen. In het geval van een string het liefst hetzelfde zodat ik dingen kan wijzigen binnen een string. Python doet dat helaas niet voor string objects aangezien die immutable zijn.

Verder gaat in jullie taal alles een object worden? Of zoveel mogelijk? Dus ook standaard string methods etc.

Bij mij ligt de wens om het geheel object georienteerd te hebben (ok, misschien op de controlstructures na dan), maar 'k merk dat oisyn en ik hier nogal van mening verschillen. Volgens mij wil oisyn een taal hebben die rete snel is (en daardoor ook meer statisch), en alhoewel ik performance ook belangrijk vind wil ik eigenlijk meer expressiviteit (en dus dynamischer). Toch oisyn?

Wat betreft de manier van array's afhandelen, ik stel voor om gewoon de class String te re-openen en de "public function [](arg)" te overriden ofzo voor dit soort doeleinden

maandag 8 september 2008 16:50

Acties:

0 Henk 'm!

supakeen

Hmmm over mijn vorige post, mutable strings in jullie nieuwe taal zouden problemen opleveren bij arrays omdat een mutable string als key niet echt fijn gaat werken gok ik zo.

Nog een laatste vraag, als jullie wat meer met objecten gaan werken dan PHP nu doet (de built-in types zijn verre van okay) gaan jullie het dan toe staan om bijvoorbeeld de add operator van een int-object te laten overschrijven? Zeg maar zoals Ruby dat nu doet.

maandag 8 september 2008 17:02

Acties:

0 Henk 'm!

writser

Definieer een eenvoudige ondersteuning voor threading en hoe dat terug zou moeten komen in de taal?

Geen idee, ik gooi alleen een balletje op.

Het kunnen draaien op de GPU's, ik zie niet hoe dit iets van de taal is, dat zou de VM moeten bepalen in dit geval imho.

Jullie gaan je toch vooral richten op de VM? Dan lijkt me dit interessant. Ik weet dat apple LLVM gebruikt om GLSL te compileren naar machinecode voor je CPU. Andersom gebeurt volgens mij nog niet.

Nogmaals, als je voor de universiteit (dat neem ik aan) gaat werken aan een VM dan lijkt het mij aardig om iets vernieuwends te implementeren. Jullie voorstel is een beetje "meer van het zelfde". Maar goed, dat is maar mijn mening. Het blijft een mooi project.

Onvoorstelbaar!

maandag 8 september 2008 17:13

Acties:

0 Henk 'm!

roy-t

.oisyn schreef op maandag 08 september 2008 @ 15:44:
Ik denk dat jouw definities niet helemaal kloppen. Een method is óók een function (maar een function niet per definitie een method). Dus de naamgeving is niet fout, en het is een beetje loos om de taal te compliceren met extra keywords. Daarnaast is het onhandig bij refactoring (je kunt een static method niet makkelijk naar buiten verplaatsen of andersom).

Of moeten we functies die een bool returnen ook maar gewoon predicates noemen? Of functies die niets returnen procedures (Basic doet dit bijvoorbeeld)?

als ik de volgende definitie neem (gevonden met google)

Methods apply directly to a single object, that is an instance of a type, while functions are more general, applying to the entire type.

The main difference is that methods implicitly contain a reference to the object it's being invoked on, and thus will have immediate access to all of the objects fields. A function on the other hand will only have immediate access to a types globals and constants.

Dan gaat het in dit code voorbeeld juist om een method en niet een functie (nouja zonder er static voor te zetten zou het een function zijn, maar vanwaar dan het keyword static? maar zou jij de definitie/het verschil tussen methods en functions eens kort kunnen toelichten?

Verder snap ik ook niet 100% waarom er uberhaupt function in staat maar niet direct wat het als (het returntype) zoals in bijvoorbeeld C#. Maargoed ik ben 'slechts' student en nog niet professioneel bezig

.

~ Mijn prog blog!

maandag 8 september 2008 17:16

Acties:

0 Henk 'm!

prototype

Cheer Bear

writser schreef op maandag 08 september 2008 @ 17:02:
Jullie gaan je toch vooral richten op de VM? Dan lijkt me dit interessant. Ik weet dat apple LLVM gebruikt om GLSL te compileren naar machinecode voor je CPU. Andersom gebeurt volgens mij nog niet.

Nogmaals, als je voor de universiteit (dat neem ik aan) gaat werken aan een VM dan lijkt het mij aardig om iets vernieuwends te implementeren. Jullie voorstel is een beetje "meer van het zelfde". Maar goed, dat is maar mijn mening. Het blijft een mooi project.

Om iets vernieuwends te implementeren zou ik eerst graag hetgeen onder de knie willen hebben wat al bedacht is

Ik zit me momenteel ook in te lezen op incremental code compilation door gebruik te maken van trace trees ipv een control flow graph. Dat is een techniek dat momenteel b.v. toegepast wordt in tracemonkey van mozilla, dat met een kleinere memory footprint b.v. jit compilation kan bewerkstelligen. Hiervoor neemt het een zekere executie pad op (een trace) om deze vervolgens te optimaliseren ipv dat hij dat doet adhv een graaf (veel duurder). Dit is een van de voorbeelden van dingen die momenteel experimenteel zijn en mogelijk een weg kunnen vinden in de VM.

LLVM is idd hetgeen dat ik heb voorgesteld en ik weet ook zo uit m'n hoofd niet of het het omgekeerde doet, 'k kan het wel even vragen aan de mensen van apple.

maandag 8 september 2008 17:21

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op maandag 08 september 2008 @ 16:43:
[...]

Bij mij ligt de wens om het geheel object georienteerd te hebben (ok, misschien op de controlstructures na dan), maar 'k merk dat oisyn en ik hier nogal van mening verschillen.

Waarom zou achter een int geen object kunnen zitten? Ik ben daar verder niet op tegen hoor

. Control structures als objects vind ik dan weer te ver gaan.

Nu we het hier toch over hebben, een klein beetje gerelateerd hieraan is dat ik graag zou zien dat alles een expressie is. Dus ook een for-loop oid. Echter denk ik niet dat ik dat wil doorzetten, omdat dat impliceert dat er overal statement terminators achter moeten

code:

if (bla)
{
    // whatever
}; // <-- irritant
foo();

Of we moeten de regel weer terughalen dat een newline ook mag als statement terminator. Maar daar wil ik persoonlijk niet aan

Volgens mij wil oisyn een taal hebben die rete snel is (en daardoor ook meer statisch)

Ik vind performance een belangrijk oogpunt, maar niet doorslaggevend. Ik wil statische types om bepaalde fouten tijdens het compilen al te vinden, en om code zichzelf meer te laten documenteren. Dat dat ook optimalisatiemogelijkheden biedt is daarbij mooi meegenomen, maar op zich niet het doel van de stricte types. Verder weerhoudt het de gebruiker niet van om alle variabelen als 'var' te definieren.

Echter, om even terug te komen op een opmerking die je eerder maakte, hoewel je 'var' op sommige plekken kunt vermijden (bijv. bij functie argumenten), ben ik wel van mening dat je variabelen gewoon moet declareren omdat anders scoping rules onduidelijk zijn.

code:

num = 23;

function foo()
{
    for (i = 0; i < num; i++) // i en num uit de global scope?
        output(i);
}

for (i = 0; i < 4; i++)
{
   // wat code
    foo(); // verneukt deze aanroep van foo() de 'i' van deze loop?
}

PHP lost dat op door variabelen te moeten declareren als global voor vars uit de global scope. Vind ik persoonlijk een kutoplossing. Javascript heeft ook 'var' om variabelen te declareren in local scope, en zo niet dan insert ie ze in global scope. Betere oplossing dan PHP, maar als je het een keer vergeet krijg je ineens vage bugs.

Vandaar mijn keuze: variabelen verplicht declareren.

[ Voor 12% gewijzigd door .oisyn op 08-09-2008 17:28 ]

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.

maandag 8 september 2008 17:22

Acties:

0 Henk 'm!

user109731

.oisyn schreef op maandag 08 september 2008 @ 12:03:
Ik vind het dus gewoon verwarrend, en er moet dus imho iets omheen om de variabelen te groeperen. Of je dat nou doet met <...> of met (...) is mij verder om het even. Ik zat er overigens aan te denken om het maar (...) te maken, want het mooie daarvan is is dat er dan geen verschil meer is tussen een tuple van 1 expressie en gewoon een expressie.

Enkel dat specifieke geval of overal waar je nu <...> gebruikt? In Python heeft de (...) syntax het volgende 'nadeel':

Python:

1 2	x = (1) # int y = (1,) # tuple

prototype schreef op maandag 08 september 2008 @ 16:43:
Wat betreft de manier van array's afhandelen, ik stel voor om gewoon de class String te re-openen en de "public function [](arg)" te overriden ofzo voor dit soort doeleinden

Ook om iets te setten? Voor een (immutable) string misschien niet relevant, maar wel voor andere objecten. Volgens mij levert operator[] in C++ een reference op, maar C# heeft bij gebrek daaraan een speciale indexer-syntax en Python heeft bijv. get/set 'magic methods'.

Hoe denken jullie over syntactic sugar voor properties, zoals in C# 3.0?

maandag 8 september 2008 17:24

Acties:

0 Henk 'm!

supakeen

prototype schreef op maandag 08 september 2008 @ 16:53:
[...]

Ik wil het sowiesow toestaan om de + operator te overloaden, zodat je b.v. een class Vector kan hebben met een overloaded + operator die als argument een vector verwacht. Zo kan je wat leesbaarder vector berekeningen uitvoeren.

Da's natuurlijk niet de + operator van de built-in type (bijvoorbeeld int of float).

maandag 8 september 2008 17:26

Acties:

0 Henk 'm!

prototype

Cheer Bear

roy-t schreef op maandag 08 september 2008 @ 17:13:
als ik de volgende definitie neem (gevonden met google)

Dan gaat het in dit code voorbeeld juist om een method en niet een functie (nouja zonder er static voor te zetten zou het een function zijn, maar vanwaar dan het keyword static? maar zou jij de definitie/het verschil tussen methods en functions eens kort kunnen toelichten?

Verder snap ik ook niet 100% waarom er uberhaupt function in staat maar niet direct wat het als (het returntype) zoals in bijvoorbeeld C#. Maargoed ik ben 'slechts' student en nog niet professioneel bezig .

Lees je eens in op covariantie en contravariantie. Een methode zou je hierbij kunnen zien als een specialisatie op een function (method is covariant aan function), waarbij een function niet per definitie dus een methode hoeft te zijn (function is contravariant aan method). Dat is hetzelfde zeggen als dat een Appel een fruit is, maar dat een fruit niet per definitie een appel is. Wat oisyn je probeert duidelijk te maken is precies hetzelfde, ook al wordt in deze context idd gerefereerd naar een methode, een methode is ook een functie (maar andersom dus niet). We noemen hem hier gewoon abstracter dan hij daadwerkelijk is. Om het voorbeeld naar absurditeit te trekken, we spreken ook over object orientatie en niet (Set, HashMap, etc... objecten orientatie). Bovendien, zoals oisyn het al heeft gezegd, het is niet handig om de grammatica nog complexer te maken door het introduceren van nieuwe keywords (die hier ook helemaal niet nodig zijn).

Een static function duidt in deze context van een __module__ aan dat deze module gebonden is. Een function die niet voorzien is van een static keyword mag bij mixin gebruik maken van de this pointer van de klasse waarin hij gemixed in wordt, itt iets dat statisch is dus.

Hetgeen mbt returntypes e.d., de taal is ontworpen vanuit het oogpunt om een dialect te worden op een taal waar vrijwel iedereen al mee bekend is: PHP. Vandaar zekere quirks die je ook in deze taal aantreft.

Overigens, student zijn heeft er helemaal niks mee te maken. Ik ben zelf ook student

Charlie Murphy schreef op maandag 08 september 2008 @ 17:24:
[...]

Da's natuurlijk niet de + operator van de built-in type (bijvoorbeeld int of float).

Gewoon de Integer of Float class reopenen en +(arg) daarin overriden?

[ Voor 7% gewijzigd door prototype op 08-09-2008 17:38 ]

maandag 8 september 2008 17:31

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op maandag 08 september 2008 @ 17:26:
Hetgeen mbt returntypes e.d., de taal is ontworpen vanuit het oogpunt om een dialect te worden op een taal waar vrijwel iedereen al mee bekend is: PHP. Vandaar zekere quirks die je ook in deze taal aantreft.

Mijn keuze voor function was overigens voornamelijk om het parsen van lambda's te vergemakkelijken

, en ik vond het logischer om dat dan ook consistent door te trekken naar gewone functie definities.

[ Voor 10% gewijzigd door .oisyn op 08-09-2008 17: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.

maandag 8 september 2008 17:45

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op maandag 08 september 2008 @ 17:21:
[...]

Waarom zou achter een int geen object kunnen zitten? Ik ben daar verder niet op tegen hoor . Control structures als objects vind ik dan weer te ver gaan.

Nu gaan alle smalltalk mensen ons uitlachen

[...]

Ik vind performance een belangrijk oogpunt, maar niet doorslaggevend. Ik wil statische types om bepaalde fouten tijdens het compilen al te vinden, en om code zichzelf meer te laten documenteren. Dat dat ook optimalisatiemogelijkheden biedt is daarbij mooi meegenomen, maar op zich niet het doel van de stricte types. Verder weerhoudt het de gebruiker niet van om alle variabelen als 'var' te definieren.

Echter, om even terug te komen op een opmerking die je eerder maakte, hoewel je 'var' op sommige plekken kunt vermijden (bijv. bij functie argumenten), ben ik wel van mening dat je variabelen gewoon moet declareren omdat anders scoping rules onduidelijk zijn.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
num = 23;

function foo()
{
    for (i = 0; i < num; i++) // i en num uit de global scope?
        output(i);
}

for (i = 0; i < 4; i++)
{
   // wat code
    foo(); // verneukt deze aanroep van foo() de 'i' van deze loop?
}

Nee, dat gaat niet fout. Een function (en dus geen closure in dit geval) moet gewoon een aparte scope hebben. Er mag dus niet zomaar naar num gerefereerd worden vanuit die functie, daar is niks kuts aan imho, Ruby doet dat ook zo dus hoe kan ik dat kut vinden

. De i in foo() is gewoon die van foo's for loop. De i van de 2e forloop is gewoon gebonden aan diezelfde forloop! Er is hier geen closure imho.

[ Voor 4% gewijzigd door prototype op 08-09-2008 17:49 ]

maandag 8 september 2008 17:49

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Hoe los je dan op dat je wel variabelen uit de globale scope kunt accessen?
Bovendien vind ik het wél een closure. De code was stieken een snippet uit een iets groter stukje code, namelijk:

code:

function bar()
{
    num = 23;

    function foo()
    {
        for (i = 0; i < num; i++) // i en num uit de global scope?
            output(i);
    }

    for (i = 0; i < 4; i++)
    {
        // wat code
        foo(); // verneukt deze aanroep van foo() de 'i' van deze loop?
    }
}

En nu?

Je kunt natuurlijk arguen dat i bij de definitie van foo() nog niet was gedefinieerd, dus foo() introduceert z'n eigen i. Maar als iemand dan toevallig wel een i boven foo() definieert verandert plots de werking van de code. Dat is dus vragen om moeilijkheden imho.
Vandaar de correcte code zoals ik het zou willen zien:

code:

num = 23;

function foo()
{
    for (var i = 0; i < num; i++) // num uit de global scope, i local
        output(i);
}

for (var i = 0; i < 4; i++)
{
   // wat code
    foo(); // geen probleem meer
}

En nameless of niet, een functie gedraagt zich altijd als closure.

[ Voor 39% gewijzigd door .oisyn op 08-09-2008 17: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.

maandag 8 september 2008 17:53

Acties:

0 Henk 'm!

roy-t

Oh een functie staat hyrargisch dus juist boven een method, ik las het misschien verkeerd maar ik dacht dat Oisyn het juist andersom vertelde.

In dat geval is een function inderdaad juist de naam die ik zou gebruiken, mijn excuses.

(en jep jij bent ook student, maar voordat ik aan mijn master begin ben ik nog wel even bezig. Het niveau van andere beginnende Inf. studenten hier op de uni valt me trouwens erg tegen, bijna niemand heeft al eens iets gemaakt, laat staan iets wat nu echt gebruikt wordt door een bedrijf ofzo... (ik dacht dat iedereen al een stuk verder zou zijn, maar somehow ben ik van mijn klas veruit het verste, achja ze zullen wel snel bij gewerkt worden aangezien ik al wat eindejaars vakken gehad heb (wegens studiewisseling halverwege) en die waren toch op redelijk niveau).

~ Mijn prog blog!

maandag 8 september 2008 18:00

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op maandag 08 september 2008 @ 17:49:
Hoe los je dan op dat je wel variabelen uit de globale scope kunt accessen?
Bovendien vind ik het wél een closure. De code was stieken een snippet uit een iets groter stukje code, namelijk:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function bar()
{
    num = 23;

    function foo()
    {
        for (i = 0; i < num; i++) // i en num uit de global scope?
            output(i);
    }

    for (i = 0; i < 4; i++)
    {
        // wat code
        foo(); // verneukt deze aanroep van foo() de 'i' van deze loop?
    }
}
En nu?

Je kunt natuurlijk arguen dat i bij de definitie van foo() nog niet was gedefinieerd, dus foo() introduceert z'n eigen i. Maar als iemand dan toevallig wel een i boven foo() definieert verandert plots de werking van de code. Dat is dus vragen om moeilijkheden imho.
Vandaar de correcte code zoals ik het zou willen zien:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
num = 23;

function foo()
{
    for (var i = 0; i < num; i++) // num uit de global scope, i local
        output(i);
}

for (var i = 0; i < 4; i++)
{
   // wat code
    foo(); // geen probleem meer
}
En nameless of niet, een functie gedraagt zich altijd als closure.

Een function dient imho z'n eigen scope te hebben omdat die function anders in feite gewoon elke keer een global mee krijgt. Je kan van geen enkele function dan meer garanderen dat deze re-entrant safe is. Vandaar dat ik dus de regel wil introduceren dat een named function gewoon zijn eigen scope krijgt. Een closure dien je dan aan te maken mbv een unnamed function, e.g.

code:

num = 5
foo = function() {
    println(num)
}

maandag 8 september 2008 18:10

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Maw, in jouw voorstel is er dus geen enkele manier om globale variabelen vanuit een niet-closure te accessen, en als je dat wel wilt dan moet je er maar een unnamed function van maken? Ik vind dat op z'n zachtst gezegd onhandig

.

Bovendien is je stelling dat je het van geen enkele functie meer kunt garanderen alleen correct als je aanhoudt dat je variabelen niet hoeft te declareren. Dat is in mijn voorstel juist wel het geval, en dus kun je ook in mijn voorstel garanderen dat functies re-entrant safe zijn - ze gebruiken dan alleen maar variabelen die ze zelf hebben gedeclareerd.

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.

maandag 8 september 2008 18:29

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op maandag 08 september 2008 @ 18:10:
Maw, in jouw voorstel is er dus geen enkele manier om globale variabelen vanuit een niet-closure te accessen, en als je dat wel wilt dan moet je er maar een unnamed function van maken? Ik vind dat op z'n zachtst gezegd onhandig .

Een globale variabele gebruiken vanuit een functie is imho bad practice mbt re-entrant safety. Afgezien van constanten zie ik niet in waarom je variabelen uit de global scope in een functie wil gebruiken. Constanten wil ik dus wel accessible laten zijn vanuit methoden.

Je zult een unnamed function ervoor moeten maken idd omdat dit in feite een expressie is, that is, a = function(args...) { body } is eigenlijk hetzelfde als a = new Function(body, args...);. Als we de taal eager evaluating maken, dan vind ik het meer dan logisch om het op deze wijze te doen, omdat body eventueel een composite expressie is die bij evaluatie ook bij de scope mag van hetgeen dat erbuiten staat.

Bovendien is je stelling dat je het van geen enkele functie meer kunt garanderen alleen correct als je aanhoudt dat je variabelen niet hoeft te declareren. Dat is in mijn voorstel juist wel het geval, en dus kun je ook in mijn voorstel garanderen dat functies re-entrant safe zijn - ze gebruiken dan alleen maar variabelen die ze zelf hebben gedeclareerd.

Ik heb ook niet anders beweerd, en dit aangekaart om mijn beweegredenen te noemen van een oplossing die niet variabel declaratie vereist maar toch re-entrant safety kan garanderen.

maandag 8 september 2008 18:34

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

In mijn optiek is een programmeertaal méér dan alleen wat syntax. Men heeft het niet over een VM en vervolgens wordt er gepraat over grammaticale details - ook niet onbelangrijk natuurlijk.

Als we uitgaan van de appbase van PHP dan zie je eigenlijk dat er vooral behoefte is aan de mogelijkheid tot (auto)threading en bijv. geïntergreerde DAL's (XML, SQL etc), validatieklassen, resource management etc. Als je je dus concurrerend tov van PHP wilt opstellen dan zal je vooral dié punten moeten benadrukken. En bijvoorbeeld een goede geïntergreerde toolkit moeten leveren voor GUI.

Maargoed dan praten we dus niet meer over een 'taal' maar een platform. PHP is samen met Apache en bijv. MySQL een platform (LAMP-achtige constructues), maar niet losstaand (imo). Dit terwijl Java of .NET op zichzelf wél een platform is - waar dan wel weer connectors voor nodig zijn.

Het feit dat men vaak PHP als bagger kwalificeert is omdat de userbase gewoon veel rotzooi maakt die de 'professionals' dan mogen opruimen. En toch kan een goede PHP-applicatie veel lichter (en goedkoper) zijn dan een compleet Java-geörienteerd systeem.

btt: Mijn mening over globals is dat ze vies, eng en niet threadsafe zijn (gelukkig is PHP nog niet multithreaded). Helaas ontkom je er in veel talen niet aan om globals te (mis-)gebruiken door gebrek aan alternatieven. Dus alsjeblieft oisyn & prototype, geen globals

.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

maandag 8 september 2008 18:47

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Alles in de globale namespace zijn globals, dus ook functies en classes. Verder heeft thread-safety er weinig mee te maken. Als je static vars in functies of classes gebruikt hou je exact hetzelfde probleem, maar dan zijn het ineens geen globals meer

. Ergo, het laten verdwijnen van globale variabelen is geen oplossing voor het probleem. En van objecten rondpassen aan ctors wordt je ook niet vrolijk. En nee, singletons zijn geen oplossing voor global variabelen - singleton zijn globals. Waar imho niets mis mee is.

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.

maandag 8 september 2008 19:14

Acties:

0 Henk 'm!

prototype

Cheer Bear

roy-t schreef op maandag 08 september 2008 @ 17:53:
(en jep jij bent ook student, maar voordat ik aan mijn master begin ben ik nog wel even bezig. Het niveau van andere beginnende Inf. studenten hier op de uni valt me trouwens erg tegen, bijna niemand heeft al eens iets gemaakt, laat staan iets wat nu echt gebruikt wordt door een bedrijf ofzo... (ik dacht dat iedereen al een stuk verder zou zijn, maar somehow ben ik van mijn klas veruit het verste, achja ze zullen wel snel bij gewerkt worden aangezien ik al wat eindejaars vakken gehad heb (wegens studiewisseling halverwege) en die waren toch op redelijk niveau).

Als er een ding is dat ik heb geleerd gedurende mijn studietijd tot op heden is dat school je niet alles KAN leren. Je studie tijd is een tijd waarin je juist dit soort (on)zinnige dingen kunt doen, en dat dien je ook te doen imho. Het is een tijd waarin je nog niet vast zit aan het burgerlijk leven, van vrouw, kind en 'dat soort verplichtingen'. Het curriculum van een opleiding kan onmogelijk --alles-- bevatten, en het is aan jou om je ook te verdiepen in dingen die je interesseren. Het curriculum geeft je hooguit de basics om die verdiepingen te kunnen doen. Je voelt je misschien nu wel king of the hill op je opleiding, en dat zal misschien ook wel zo zijn, het is stom om je te meten aan anderen omdat je imho je ontwikkeling dan laat beperken adhv hoe ver de anderen zijn. Gewoon je eigen ontwikkeling maken dus gedurende deze tijd, dat scheidt het koren ook van het kaf.

maandag 8 september 2008 19:15

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Laat ik mezelf completeren; want ik bedoelde namelijk globale variabelen.

Het is waar dat alles wat je in globale/initial namespace kan worden beschouwd en aangesproken als global. Toch zit er een significant verschil tussen data die binnen verschillende scopes berschikbaar moet zijn en een globaal object. In de scope van een klasse (welke zich bijv. in een module bevindt) wil ik helemaal niets te maken hebben met eventuele globals van de 'main'. Wanneer de ontwikkelaar behoefte heeft aan gedeelte configuratiedata dan is het zijn taak om die onder te brengen in een centrale klasse - waar inderdaad wat mee gezeuld moet worden. Dit is altijd nog beter dan globals te vaak te onpas ergens op komen dagen.

Wat dat betreft mis ik een beetje het java import-statement icm packages/plugins/modules (you name it). Dit heeft niet zozeer met de taal alswel met het beoogde platform te maken.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

maandag 8 september 2008 19:48

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Namespaces dus, was al genoemd

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.

maandag 8 september 2008 19:56

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

Je hebt imo een namespace en een executionspace en dat zijn verschillende dingen. Een bepaalde klasse kan met zijn functies in een aparte namespace vallen maar qua executionspace overlappen: het verschil tussen 'code time' en execution time. Maargoed het punt is gemaakt. Ik ben benieuwd naar de implementatie.

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

dinsdag 9 september 2008 11:17

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Sorry, maar ik snap echt geen zak van wat je nou probeert te zeggen. Eerst zeg je dat je java's import en packages mist. Packages zijn gewoon namespaces, en niets meer dan dat. Ze zorgen totaal niet voor thread-safety.

In de scope van een klasse (welke zich bijv. in een module bevindt) wil ik helemaal niets te maken hebben met eventuele globals van de 'main'

Als jij dat niet wilt, dan moet je die globals niet accessen, en als main() dat niet wilt dan moet main() die globals niet exposen. Ik snap echt niet waarom je zou moeten verplichten de global namespace leeg te houden. En aangezien dat impliceert dat freeform code zoals de meeste scripttalen dat kennen dan niet meer mogelijk is wil ik er niet eens aan. Als jij je variabelen wilt afschermen dan moet je dat gewoon doen. En dit alles staat compleet los van thread-safety.

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.

dinsdag 9 september 2008 12:45

Acties:

0 Henk 'm!

prototype

Cheer Bear

@LauPro:
Misschien ten overvloede, maar 'k denk dat het goed is om te onderstrepen dat in een totaal object georienteerde taal zoals Ruby (en hopelijk ook poisyn/pinp/pimp), classes/functies/modules in feite ook objecten zijn. En wel constante objecten die in de global namespace leven.

Java's import statement doet niks anders eigenlijk dan de namespace importen, wat inhoudt dat het naast de bijbehorende classes loaden ervoor zorgt dat je niet de fully qualified name hoeft te gebruiken (tenzij er een namespace clash ontstaat als gevolg ervan en je zelf voor disambiguity dient te zorgen middels b.v. fully qualified names).

m.a.w. ook ik zie niet hoe dit te maken heeft met thread safety.

dinsdag 9 september 2008 13:55

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

prototype schreef op dinsdag 09 september 2008 @ 12:45:
classes/functies/modules in feite ook objecten zijn. En wel constante objecten die in de global namespace leven.

Ja daar zat ik aan te denken. Moeten ze wel constant zijn? Zou het niet cool zijn om te kunnen doen:

code:

function someAPIFunction()
{
   // do something
}

// ...

// lalala, somewhere in my private script
auto oldSomeAPIFunction = someAPIFunction;
someAPIFunction = function()
{
   output("someAPIFunction() is about to be called");
   oldSomeAPIFunction();
   output("someAPIFunction() was called");
}

someAPIFunction(); // calls my own wrapper

En vanaf dan worden alle calls naar someAPIFunction() gereroute naar je eigen wrapper

. Dat zou ook heerlijk zijn voor profiling en debugging.

[ Voor 13% gewijzigd door .oisyn op 09-09-2008 13:58 ]

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.

dinsdag 9 september 2008 14:14

Acties:

0 Henk 'm!

BramFokke

Dat opent deuren voor heel veel handige constructs die ook heel erg goed de soep in kunnen lopen. Het doet me een beetje denken aan Aspect Oriented Programming.

dinsdag 9 september 2008 14:14

Acties:

0 Henk 'm!

prototype

Cheer Bear

.oisyn schreef op dinsdag 09 september 2008 @ 13:55:
[...]

Ja daar zat ik aan te denken. Moeten ze wel constant zijn? Zou het niet cool zijn om te kunnen doen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function someAPIFunction()
{
   // do something
}

// ...

// lalala, somewhere in my private script
auto oldSomeAPIFunction = someAPIFunction;
someAPIFunction = function()
{
   output("someAPIFunction() is about to be called");
   oldSomeAPIFunction();
   output("someAPIFunction() was called");
}

someAPIFunction(); // calls my own wrapper
En vanaf dan worden alle calls naar someAPIFunction() gereroute naar je eigen wrapper . Dat zou ook heerlijk zijn voor profiling en debugging.

Mjah, ze hoeven idd niet constant te zijn. Wat jij nu in feite probeert te doen met zo'n situatie is eigenlijk aspect orientatie proberen toe te passen op API functies. Hoog monkeypatch gehalte is mogelijk, maar goede programmeurs zouden hier idd wel veel uit kunnen halen denk ik. In java/C# lossen ze zoiets op door annotations/attributes he? Die meta data kan dan ge-accessed worden door een runner, wat b.v. JUnit 4 ook doet.

Wat dacht je trouwens van een "catch all" methode te hebben in Object b.v., genaamd method_missing(name, args...) welke geinvoked wordt als je een methodnaam naar het object send/invoked die niet bestaat? Dien je te overriden dus in je subclasses om zo b.v. methodes on the fly genereren of zelf method dispatch te regelen. Vergelijk 't maar met PHP's magic __call function of Ruby's method_missing(name, *args) ;-)

Let wel op, wanneer je zoiets toestaat wordt een interface definitie alleen maar nog meer nutteloos.

[ Voor 5% gewijzigd door prototype op 09-09-2008 14:25 ]

dinsdag 9 september 2008 14:38

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Voor late bound objects wou ik eigenlijk een apart type introduceren waarvan je moet overerven. Een beetje a la COM's IDispatch. Om op die manier on the fly proxies te kunnen genereren voor bijv. COM, .Net of Java objecten.

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.

dinsdag 9 september 2008 14:45

Acties:

0 Henk 'm!

LauPro

Prof Mierenneuke®

.oisyn schreef op dinsdag 09 september 2008 @ 11:17:
Sorry, maar ik snap echt geen zak van wat je nou probeert te zeggen. Eerst zeg je dat je java's import en packages mist. Packages zijn gewoon namespaces, en niets meer dan dat. Ze zorgen totaal niet voor thread-safety.

Je kent neem ik aan het begrip autothreading van Perl? Je kan daar met het pure keyword zorgen dat sommige functies (in de toekomst) automatisch worden gethread. Op dat moment is het weldegelijk van belang dat bijv. je globals (in welke context dan ook) thread safe zijn.

Als jij dat niet wilt, dan moet je die globals niet accessen, en als main() dat niet wilt dan moet main() die globals niet exposen. Ik snap echt niet waarom je zou moeten verplichten de global namespace leeg te houden. En aangezien dat impliceert dat freeform code zoals de meeste scripttalen dat kennen dan niet meer mogelijk is wil ik er niet eens aan. Als jij je variabelen wilt afschermen dan moet je dat gewoon doen. En dit alles staat compleet los van thread-safety.

Het is gewoon een bepaalde mentaliteit. Compatibiliteit houden met bijv. PHP lijkt mij schier onmogelijk. Je zou mogelijk een converter kunnen schrijven maar ik vrees dat die even bruikbaar zijn als de asp->php converters. PHP heeft veel ruimte, ik denk dat je juist bij zo'n nieuw taal de kans moet aangrijpen om je developers ook een beetje op te voeden, en dus geen (super)globals te gebruiken (dus onmogelijk maken).

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

dinsdag 9 september 2008 14:52

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

LauPro schreef op dinsdag 09 september 2008 @ 14:45:
[...]
Je kent neem ik aan het begrip autothreading van Perl? Je kan daar met het pure keyword zorgen dat sommige functies (in de toekomst) automatisch worden gethread. Op dat moment is het weldegelijk van belang dat bijv. je globals (in welke context dan ook) thread safe zijn.

En wat we nou al de hele tijd duidelijk proberen te maken is dat het niet thread safe zijn niet de schuld is van globals, dus door globals te voorkomen verhelp je de problemen niet. Zelfs al zou er geen enkele statische variabele meer bestaan en kun je alleen nog maar members van objects accessen, dan nog houd je het probleem omdat dat ene object dan geshared gaat worden tussen de verschillende threads.

Thread safety heeft te maken met concurrent access naar een bepaalde state. Het doet er daarbij niet toe of die state global is of niet.

Het is gewoon een bepaalde mentaliteit. Compatibiliteit houden met bijv. PHP lijkt mij schier onmogelijk.

Ik had het over het supporten van freeform code. Er zit nogal een grote afstand tussen het supporten van een bepaalde feature en volledige PHP compatibiliteit

.

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.

dinsdag 9 september 2008 14:58

Acties:

0 Henk 'm!

prototype

Cheer Bear

LauPro schreef op dinsdag 09 september 2008 @ 14:45:
[...]
Je kent neem ik aan het begrip autothreading van Perl? Je kan daar met het pure keyword zorgen dat sommige functies (in de toekomst) automatisch worden gethread. Op dat moment is het weldegelijk van belang dat bijv. je globals (in welke context dan ook) thread safe zijn.

Autothreading heb ik wat van meegepikt op de Perl 6 mailinglist, maar daar zijn ze ten eerste nog lang niet uit wat het precies moet doen. Wat ik je in ieder geval wel kan zeggen adhv wat ik gelezen heb is dat autothreading de compiler laat bepalen dat de functie multithreaded gedraaid mag worden. Van een formele methoden standpunt, mag dit alleen plaatsvinden als thread-safety gegerandeerd kan worden. Een van die manieren is dat de threads geen waarneembare side-effects mogen bewerkstelligen mbt tot elkaar en dat kan --heel kort door de bocht-- door niks te delen. Globals zijn idd accessible vanuit de threads, MAAR, het is hier aan de programmeur imho om hier zelf locking mechanismen voor te bedenken (i.e. zelf maar een semafoor hiervoor gebruiken). Je zou ook kunnen zeggen dat code dat gemarked wordt voor autothreading gewoon geen enkele side-effect mag bewerkstelligen op de global scope, maar dan kan je eigenlijk niet echt bijzonder nuttige software schrijven imho

Oftewel, imho een kwestie van zelf goed locken zoals je normaal al met threaden doet.

[...]
Het is gewoon een bepaalde mentaliteit. Compatibiliteit houden met bijv. PHP lijkt mij schier onmogelijk. Je zou mogelijk een converter kunnen schrijven maar ik vrees dat die even bruikbaar zijn als de asp->php converters. PHP heeft veel ruimte, ik denk dat je juist bij zo'n nieuw taal de kans moet aangrijpen om je developers ook een beetje op te voeden, en dus geen (super)globals te gebruiken (dus onmogelijk maken).

Je denkt teveel op niveau van een hogere taal naar een hogere taal vertaling. In het geval van PHP zouden we er een parser voor kunnen schrijven een een code generator die deze omzet naar de bytecode die onze VM begrijpt. Maar dan heb je alleen de grammatica en moet je nog die shitloads aan libraries doen... daar waag ik me liever niet aan

Wederom, ik snap je argument over globals niet.

dinsdag 9 september 2008 17:20

Acties:

0 Henk 'm!

RayNbow

Kirika <3

.oisyn schreef op dinsdag 09 september 2008 @ 13:55:
[...]

Ja daar zat ik aan te denken. Moeten ze wel constant zijn? Zou het niet cool zijn om te kunnen doen:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function someAPIFunction()
{
   // do something
}

// ...

// lalala, somewhere in my private script
auto oldSomeAPIFunction = someAPIFunction;
someAPIFunction = function()
{
   output("someAPIFunction() is about to be called");
   oldSomeAPIFunction();
   output("someAPIFunction() was called");
}

someAPIFunction(); // calls my own wrapper
En vanaf dan worden alle calls naar someAPIFunction() gereroute naar je eigen wrapper . Dat zou ook heerlijk zijn voor profiling en debugging.

Dit is mogelijk in Python.

Sterker nog, ik heb dit een keer toegepast omdat xmlrpclib niet aan mijn wensen voldeed. Het serializen van een object was nog al primitief (=dict dump), dus ik voegde wat toe om te zorgen dat objecten met een serialize/deserialize methode netjes automagisch werden omgezet.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

dinsdag 16 september 2008 15:01

Acties:

0 Henk 'm!

Verwijderd

^{Is dit een stille dood gestorven?}

dinsdag 16 september 2008 15:12

Acties:

0 Henk 'm!

.Gertjan.

Owl!

RayNbow schreef op dinsdag 09 september 2008 @ 17:20:
[...]

Dit is mogelijk in Python.

Sterker nog, ik heb dit een keer toegepast omdat xmlrpclib niet aan mijn wensen voldeed. Het serializen van een object was nog al primitief (=dict dump), dus ik voegde wat toe om te zorgen dat objecten met een serialize/deserialize methode netjes automagisch werden omgezet.

Dit werkt ook in JavaScript... Daar kan je een functie als "variabele" gebruiken. En dan kan je daarna variabele ook nog aanroepen.

code:

function MyFunction(x) {
}

var oldFunction = MyFunction;

function MyFunction(x) {
  //This is the new function
  //Call the old one
  oldFunction(x);
}

Werkt perfect. Heb dit in .NET 1.1 een paar keer moeten gebruiken om checks/functionaliteit in te bouwen voordat de postback werd aangeroepen. Minder leuk was het toen Microsoft besloot in 2.0 de postback functies pas later op in de pagina aan te maken waardoor mijn scripts de mist in gingen.

The #1 programmer excuse for legitimately slacking off: "My code's compiling"
Firesphere: Sommige mensen verdienen gewoon een High Five. In the Face. With a chair.

dinsdag 16 september 2008 15:29

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

.Gertjan. schreef op dinsdag 16 september 2008 @ 15:12:
[...]

Dit werkt ook in JavaScript... Daar kan je een functie als "variabele" gebruiken. En dan kan je daarna variabele ook nog aanroepen.

Big deal, dat kan in zoveel talen

. De clue was dat de functiedefinitie zelf ook een variabele introduceerde die je kan herassignen. Maar ik zie dat dat in javascript ook kan:

JavaScript:

1 2	function bla() { } bla = 4;

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.

dinsdag 16 september 2008 16:21

Acties:

0 Henk 'm!

prototype

Cheer Bear

Verwijderd schreef op dinsdag 16 september 2008 @ 15:01:
^{Is dit een stille dood gestorven?}

Nee, maar .oisyn heeft een fulltime job als game developer en ik studeer en draai een zaak ernaast

Dus het gaat misschien wat langzamer dan we zouden hopen

dinsdag 16 september 2008 22:46

Acties:

0 Henk 'm!

Verwijderd

Wat mij betreft is kwaliteit in dit geval een stuk belangrijker dan kwantiteit. Niemand zit te wachten op nòg zo'n gedrocht als PHP.

Niet dat ik me zorgen maak over de kwaliteit overigens, voor zover ik er iets van begrijp.

vrijdag 31 oktober 2008 18:29

Acties:

0 Henk 'm!

prototype

Cheer Bear

Even een kleine update:
Heb het helaas momenteel ontzettend druk, maar ik wil jullie wel even laten weten dat ik hier nog mee bezig ben: in m'n vrije tijd zit ik me in te lezen op LLVM. Handig om te lezen denk ik en te doen om je C++ op te poetsen

Indien er ook nog mensen hier zijn die geinteresseerd zijn in hoe je uberhaupt moet beginnen met een programmeertaal te implementeren (wat de LLVM tutorial opzich ook al doet, maar beter teveel dan te weinig>?

), heb ik een uitgebreid artikel geschreven op m'n blog over hoe je dit zou moeten doen voor de esoterische taal Brainfuck.

Ook is m'n onderneming benaderd door een zeker IT bedrijf waarvan de meesten wel een muziekspeler hebben om te kijken of er een mogelijkheid is om ons te laten werken aan een VM voor hun besturingssysteem, gebruikmakend van LLVM. Dit zal hoogstwaarschijnlijk als open source gepubliceerd mogen worden en biedt me dus eventueel de kans om hier fulltime aan te werken. Er staat nog niks vast though, maar stay tuned :-)

[ Voor 27% gewijzigd door prototype op 31-10-2008 18:39 ]

vrijdag 31 oktober 2008 21:16

Acties:

0 Henk 'm!

YopY

Om er maar eens in te springen, =D.

quote: prototype
Wat dacht je trouwens van een "catch all" methode te hebben in Object b.v., genaamd method_missing(name, args...) welke geinvoked wordt als je een methodnaam naar het object send/invoked die niet bestaat? Dien je te overriden dus in je subclasses om zo b.v. methodes on the fly genereren of zelf method dispatch te regelen. Vergelijk 't maar met PHP's magic __call function of Ruby's method_missing(name, *args) ;-)

Alsjeblieft niet, als je een method probeert uit te voeren die niet bestaat, moet je script een fout geven omdat jij als programmeur dan een fout gemaakt hebt. Als je netjes af wilt vangen dat een niet-bestaande methode aangeroepen wordt, gooi dan een MethodNotFoundException (als je taal OO moet worden, danwel exceptions heeft), zodat de ontwikkelaar die nog af kan vangen.

In mijn tijd (opa vertelt) had ik een controller gemaakt in het Zend Framework die z'n superclass ook een __call()-functie had, die niet-bestaande actions opving en (mijn fout) de persoon terugstuurde naar de index van die controller, wat leidde tot een oneindige loop toen ook de index niet bestond,

.

Nee, laat het programma of op z'n spreekwoordelijke bek gaan, of laat het programma een (unchecked?) exception gooien, zodat een catch-all voor exceptions op z'n minst nog een fout kan weergeven.

Over het 'encapsulaten' van een functie binnen een andere functie, dat lijkt mij een soort van inline AOP, wat overigens niet eens zo'n slecht idee zou zijn. Ik heb me niet kunnen verdiepen in AOP, maar wat ik er van begreep (in de Java-implementatie) is dat je een class schrijft die via via maar tussen een client en een ander gepropt moest worden, maar het lijkt mij dat je het overzicht dan snel verliest, zeker in grotere projecten, zeker als je het veel gebruikt. Als je het gewoon inline kunt doen, danwel zo dicht mogelijk bij het geencapsuleerde stuk code, zou het een stuk beter zijn. Maar zoals gezegd, geen ervaring mee.

vrijdag 31 oktober 2008 21:51

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

YopY schreef op vrijdag 31 oktober 2008 @ 21:16:
Alsjeblieft niet, als je een method probeert uit te voeren die niet bestaat, moet je script een fout geven omdat jij als programmeur dan een fout gemaakt hebt. Als je netjes af wilt vangen dat een niet-bestaande methode aangeroepen wordt, gooi dan een MethodNotFoundException (als je taal OO moet worden, danwel exceptions heeft), zodat de ontwikkelaar die nog af kan vangen.

Alsjeblieft wel. Ja, het is een opening voor vieze hacks, maar het is tevens een mogelijkheid om late dispatching te implementeren. Denk bijvoorbeeld aan objecten uit een andere taal / platform (COM, .Net, Java, ActiveScript), zonder dat je daar at compile-time al type definities voor nodig hebt.

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.

vrijdag 31 oktober 2008 22:15

Acties:

0 Henk 'm!

RayNbow

Kirika <3

quote: http://www.laputan.org/ref89/ref89.html
When a message is sent to a Smalltalk-80 object, the method dictionaries associated with that object's class and its superclasses are searched at runtime. If none of these classes implement a method for a given message, the Smalltalk virtual machine sends the object the message doesNotUnderstand:. The original message selector and message arguments are bundled together in a Message object and passed as the argument to doesNotUnderstand:. The default method for this message is stored in class Object. This method invokes the Smalltalk debugger, since sending an object a message it does not implement is usually a sign of programmer error. However, objects that override doesNotUnderstand: can intercept unimplemented message at runtime, and process them as they see fit.

Smalltalk $_/-\o_$

Addendum:
Smalltalk met een type-sausje: Strongtalk: Typechecking Smalltalk in a Production Environment (OOPSLA '93)

[ Voor 10% gewijzigd door RayNbow op 31-10-2008 22:35 ]

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

zaterdag 1 november 2008 06:49

Acties:

0 Henk 'm!

prototype

Cheer Bear

YopY schreef op vrijdag 31 oktober 2008 @ 21:16:
Om er maar eens in te springen, =D.

[...]

Alsjeblieft niet, als je een method probeert uit te voeren die niet bestaat, moet je script een fout geven omdat jij als programmeur dan een fout gemaakt hebt. Als je netjes af wilt vangen dat een niet-bestaande methode aangeroepen wordt, gooi dan een MethodNotFoundException (als je taal OO moet worden, danwel exceptions heeft), zodat de ontwikkelaar die nog af kan vangen.

Zie .oisyn en RayNbow. Bovendien, de default implementatie van method_missing ziet er dan ongeveer als volgt uit:

code:

class Object {
    public functon method_missing(name, args...) {
        throw new MethodNotFoundException();
    }
}

Wanneer een programmeur kiest dit te overriden, dan kan hij z'n eigen gedrag eraan toe kennen wat uitermate handig is voor meta programming. Men kan op deze wijze dan dynamisch methoden "genereren". Mensen die hier niks van willen weten moeten deze methode gewoon niet overriden dan

In mijn tijd (opa vertelt) had ik een controller gemaakt in het Zend Framework die z'n superclass ook een __call()-functie had, die niet-bestaande actions opving en (mijn fout) de persoon terugstuurde naar de index van die controller, wat leidde tot een oneindige loop toen ook de index niet bestond, .

Tsjah, with great power comes great responsibility. Ik zeg hier trouwens niet mee dat PHP great powers heeft, integendeel

Nee, laat het programma of op z'n spreekwoordelijke bek gaan, of laat het programma een (unchecked?) exception gooien, zodat een catch-all voor exceptions op z'n minst nog een fout kan weergeven.

Zie code example. Default behaviour voorziet hierin. Ik ben ook van de filosofie, if code fails, it should fail hard. Tegelijkertijd daarentegen zie ik het belang erin van de dynamische aard van een programmeertaal er in te houden.

Over het 'encapsulaten' van een functie binnen een andere functie, dat lijkt mij een soort van inline AOP, wat overigens niet eens zo'n slecht idee zou zijn. Ik heb me niet kunnen verdiepen in AOP, maar wat ik er van begreep (in de Java-implementatie) is dat je een class schrijft die via via maar tussen een client en een ander gepropt moest worden, maar het lijkt mij dat je het overzicht dan snel verliest, zeker in grotere projecten, zeker als je het veel gebruikt. Als je het gewoon inline kunt doen, danwel zo dicht mogelijk bij het geencapsuleerde stuk code, zou het een stuk beter zijn. Maar zoals gezegd, geen ervaring mee.

Closures hebben niet veel met AOP te maken. Aspect orientation is gedrag op bestaande code plakken zonder deze bestaande code te hoeven aan te passen, om zodoende cross cutting concerns, tangling en scattering tegen te gaan. Dit "plakken", i.e. superimposen, gebeurd veelal in een aparte weave fase en dit leidt vaak tot het probleem van "obliviousness". Hierbij ontstaat er dan een fout tijdens runtime die een bepaalde lijn aan code aanhaalt als zijnde de schuldige, echter is deze lijn aan code lastig te traceren in de originele code omdat het een lijntje code uit het "opgeplakte" gedrag kan zijn. Daarom wil ik geen AOP op deze wijze introduceren aan de taal. Then again, de taal kan me eigenlijk nog steeds bijster weinig schelen, het gaat me er echt om dat die VM uber vet gebouwd kan worden.

Closures is meer bedoeld om scope bindings te bewerkstelligen, het liefst op zo'n wijze dat dit kan voortvloeien uit de lexicale context ipv dat je dit expliciet moet opgeven (zoals dat 't geval is bij PHP). Zo kan je lekker blokken code schrijven die je binnen een methode misschien vaker gebruikt of die je kan gebruiken bij het aanroepen van een andere methode.

vrijdag 7 november 2008 18:42

Acties:

0 Henk 'm!

user109731

* kick *

Het zou IMHO heel tof zijn om een dynamische taal als Python of Ruby te hebben, waarbij je optioneel types kunt opgeven. Dat kun je dan in de CPU-intensieve functies van het programma gebruiken, zodat de JIT betere code kan genereren. Volgens mij zie ik dat in .oisyn's ontwerp terug, dat maakt het erg interessant en kan deze taal best een succes maken

zaterdag 8 november 2008 15:22

Acties:

0 Henk 'm!

Verwijderd

.oisyn en prototype, kunnen jullie niet beter je tijd en kennis besteden aan Ruby of Python?
Jullie zijn nu bezig aan 'yet another script language' waar niemand op zit te wachten, terwijl de meeste dingen die jullie willen al in Ruby of Python kunnen.

zaterdag 8 november 2008 15:25

Acties:

0 Henk 'm!

Verwijderd

offtopic:
They do it because they can! Het lijkt me toch wel een vrij nuttige tijdsbesteding hoor, wellicht dat de taal zelf niet ontzettend veel praktisch nut heeft, maar dommer zullen ze er sowieso niet van worden en dat is opzich al heel wat waard.

zaterdag 8 november 2008 15:45

Acties:

0 Henk 'm!

Verwijderd

Worteltaart, volledig mee eens, maar ze zijn nu tijd en kennis aan het investeren in een nieuw project terwijl dat m.i. zinvoller is in bv. Ruby of Python.
'Because you can' is leuk voor thuis.

zaterdag 8 november 2008 17:03

Acties:

0 Henk 'm!

Verwijderd

prototype schreef op vrijdag 31 oktober 2008 @ 18:29:
Even een kleine update:
Heb het helaas momenteel ontzettend druk, maar ik wil jullie wel even laten weten dat ik hier nog mee bezig ben: in m'n vrije tijd zit ik me in te lezen op LLVM. Handig om te lezen denk ik en te doen om je C++ op te poetsen

Indien er ook nog mensen hier zijn die geinteresseerd zijn in hoe je uberhaupt moet beginnen met een programmeertaal te implementeren (wat de LLVM tutorial opzich ook al doet, maar beter teveel dan te weinig>? ), heb ik een uitgebreid artikel geschreven op m'n blog over hoe je dit zou moeten doen voor de esoterische taal Brainfuck.

Ook is m'n onderneming benaderd door een zeker IT bedrijf waarvan de meesten wel een muziekspeler hebben om te kijken of er een mogelijkheid is om ons te laten werken aan een VM voor hun besturingssysteem, gebruikmakend van LLVM. Dit zal hoogstwaarschijnlijk als open source gepubliceerd mogen worden en biedt me dus eventueel de kans om hier fulltime aan te werken. Er staat nog niks vast though, maar stay tuned :-)

Wow mooi verhaal op je blog over de Brainfuck compiler. Ik heb zelf nog nooit met Ruby gewerkt, en de concepten die achter een parser/compiler zitten waren me volledig onbekend. Maar erg interessant

.
Denk dat ik je parser maar eens in C# probeer te bouwen, leuke oefening

.

zaterdag 8 november 2008 19:18

Acties:

0 Henk 'm!

Verwijderd

Brainfuck is in principe in iedere taal te maken die direct een byte array aan kan spreken. Maar waarom zou je dat willen?

zaterdag 8 november 2008 19:50

Acties:

0 Henk 'm!

Toolskyn

€ 500,-

Afterlife, zoals hij zelf al zegt: leuke oefening. Volgens mij zie je uberhaupt niets in alles wat ofwel nieuw ofwel al gedaan ofwel geen praktisch nut heeft. Maar al die dingen mogen dan misschien uiteindelijk geen nut naar jou idee, maar dat hebben ze echt wel, zoals hierboven ook al een keer gezegd is. Door de hele tijd te zeggen 'wat voor zin heeft het' leer je natuurlijk nooit iets en kom je nooit een stap verder.

gewooniets.nl

zaterdag 8 november 2008 20:22

Acties:

0 Henk 'm!

prototype

Cheer Bear

Verwijderd schreef op zaterdag 08 november 2008 @ 15:22:
.oisyn en prototype, kunnen jullie niet beter je tijd en kennis besteden aan Ruby of Python?
Jullie zijn nu bezig aan 'yet another script language' waar niemand op zit te wachten, terwijl de meeste dingen die jullie willen al in Ruby of Python kunnen.

Een zeer valide vraag Afterlife, en het is dan ook om deze reden dat ik al meerdere keren heb aangegeven "niet zoveel te geven om de taal zelf" en me vooral wil focussen op wat de virtual machine moet ondersteunen. Dan zul je snel in kunnen zien dat diezelfde virtual machine voor mijn geliefde Ruby gebruikt kan worden. En dat is ook eigenlijk mijn ware intentie (mijn design keuzes zijn bijna alleen gebaseerd op smalltalk en ruby, waarbij ik de syntax zo vertrouwd mogelijk aan PHP'ers wil laten overkomen). De huidige VM van Ruby 1.9 laat nog echt veel te veel te wensen over en het is daarom om deze reden dat een zeker bedrijf me hierover heeft gecontact. Python kan op gelijke wijze ondersteund worden aangezien ze qua language features pretty much overeenkomen. Het kan hoe dan ook op het simpele feit dat ze beiden turing complete zijn.

Verwijderd schreef op zaterdag 08 november 2008 @ 19:18:
Brainfuck is in principe in iedere taal te maken die direct een byte array aan kan spreken. Maar waarom zou je dat willen?

Als je dat artikel bekijkt beschrijf ik een 3-stage compiler, van handmatig een lexer bouwen, parser bouwen en treewalker. Ik beschrijf daarbij hoe je zowel een interpreter kan bouwen evenals een target code emitter. Het is jammer dat je niet voorbij brainfuck zelf kan kijken, maar wat ik hier beschrijf zijn de general stages van compilation/interpretation die je in modern day compilers aantreft. Dat ik als voorbeeldtaal toevallig brainfuck heb gekozen om de vertaler te implementeren is simpelweg om het voor mij compacter te maken op gebied van "instructies" en "uitleg" ;-) Als ik een mini PHP ofzo had uitgelegd (om maar wat te noemen), dan was het meer lexer/parse/walk werk, maar in grote lijnen nog steeds hetzelfde. Je zou dan nog concepten als symbolic tables langs zien komen en garbage collection, maar die concepten wil ik liever uitleggen en bestuderen adhv mijn eigen VM implementatie

Het is alweer een tijdje geleden namelijk dat ik vertalerbouw heb genoten aan de Universiteit Twente en zat hierbij vast aan een taal te implementeren voor de JVM. Laatstgenoemde deed alles van JIT tot GC, en laat ik nou net die concepten handmatig eens willen implementeren

[ Voor 37% gewijzigd door prototype op 08-11-2008 20:31 ]

zaterdag 8 november 2008 21:23

Acties:

0 Henk 'm!

Verwijderd

prototype schreef op zaterdag 08 november 2008 @ 20:22:
De huidige VM van Ruby 1.9 laat nog echt veel te veel te wensen over en het is daarom om deze reden dat een zeker bedrijf me hierover heeft gecontact.

OK, prima reden. Maar ook een reden om helemaal vanaf 0 te starten terwijl je ook al de VMs van Java, .NET/Mono, LLVM, etc. hebt?

Als je dat artikel bekijkt beschrijf ik een 3-stage compiler, van handmatig een lexer bouwen, parser bouwen en treewalker. Ik beschrijf daarbij hoe je zowel een interpreter kan bouwen evenals een target code emitter. Het is jammer dat je niet voorbij brainfuck zelf kan kijken, maar wat ik hier beschrijf zijn de general stages van compilation/interpretation die je in modern day compilers aantreft.

Ik kan wel degelijk voorbij Brainfuck zelf kijken, en vond jouw blog erg interessant, maar gaf alleen aan dat je dat in elke compiler die byte arrays aankan kunt doen. C/C++, C#, VB.NET, Delphi, noem maar op...

zaterdag 8 november 2008 22:42

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Topicstarter

Verwijderd schreef op zaterdag 08 november 2008 @ 15:45:
Worteltaart, volledig mee eens, maar ze zijn nu tijd en kennis aan het investeren in een nieuw project terwijl dat m.i. zinvoller is in bv. Ruby of Python.
'Because you can' is leuk voor thuis.

Voor mij persoonlijk is het ook gewoon voor thuis. Ik ben een gamedeveloper en heb helemaal geen ambities me professioneel met language development bezig te houden. Ik vind het echter wel een interessant onderwerp en daarom houd ik me ermee bezig in een hobbysfeer. Om diezelfde reden lees ik ook boeken over oa quantum mechanica en string theory e.d.. Het mooie van dit project is dan echter dat ik er ook nog praktisch mee bezig kan zijn, wat bij natuurkunde wat lastiger wordt. En als er iets serieus uit voortvloeit dan is dat wel cool maar dat is allerminst m'n primaire doel - want dat is gewoon "doing the things I like to do". Persoonlijke ontwikkeling komt daarbij op de tweede plek, maar zelfs dat is dus niet de primaire reden

Overigens gaat momenteel al mijn aandacht uit naar de laatste GoT programming contest

[ Voor 12% gewijzigd door .oisyn op 08-11-2008 22:46 ]

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.